[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Switching technologies requiring bidirectional asymmetric LSPs?
Attila,
PONs are a good example of asymmetry at the edge
Alan
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs (IJ/ETH)
Sent: 20 April 2007 10:33
To: Igor Bryskin; Harrison,N,Neil,JCGA1 R; lberger@labn.net
Cc: i_bryskin@yahoo.com; martin.vigoureux@alcatel-lucent.fr; adrian@olddog.co.uk; ccamp@ops.ietf.org
Subject: RE: Switching technologies requiring bidirectional asymmetric LSPs?
Hi Igor, Neil, and all,
I think it is quite useful to have this discussion on networking modes, topology builder services and the relations to GMPLS LSPs.
I agree with Neil that the answer is context sensitive.
One can have Ethernet LSPs operating in different modes: co-ps and cl-ps irrespective to what these are used for, i.e, being a server layer and building a client layer topology, or being at the top of the layers and directly supporting services. However, while the former requires co-ps mode to operate properly, as pointed out by Neil, the latter can be build on co-ps and cl-ps modes primarily depending on the requirements of the service. Hence, I think (and I assume this is referred to as context sensitive by Neil) asymmetry may be useful for LSPs residing higher in the layer stack regardless of co-ps or cl-ps mode of operation.
Additionally, very much related to the layering/hierarchy, LSPs nearer to the edges of the network will likely experience asymmetry imho, compared to LSP in the core.
Regards,
Attila
Ps.: well it seems I have just repeated what has been said already, sorry!
> -----Original Message-----
> From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
> Sent: Thursday, April 19, 2007 10:51 PM
> To: neil.2.harrison@bt.com; lberger@labn.net
> Cc: i_bryskin@yahoo.com; martin.vigoureux@alcatel-lucent.fr;
> Attila Takacs (IJ/ETH); adrian@olddog.co.uk; ccamp@ops.ietf.org
> Subject: RE: Switching technologies requiring bidirectional asymmetric
> LSPs?
>
> Neil,
>
> Let's assume you've got clean co-ps connections(e.g. Ethernet
> connections). My understanding is that you believe that the bandwidth
> asymmetricity is useful for p2mp such connections, but not for p2p
> connections. Is that correct?
>
> Thanks,
> Igor
>
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of neil.2.harrison@bt.com
> Sent: Thursday, April 19, 2007 12:28 PM
> To: lberger@labn.net
> Cc: i_bryskin@yahoo.com; martin.vigoureux@alcatel-lucent.fr;
> Attila.Takacs@ericsson.com; adrian@olddog.co.uk; ccamp@ops.ietf.org
> Subject: RE: Switching technologies requiring bidirectional asymmetric
> LSPs?
>
> Lou Berger asked 19 April 2007 15:05
>
> >
> >
> > Neil,
> > I agree with Igor, much thanks for your input.
> >
> > In reading your response, it's clear that you see a place for
> > bidirectional asymmetric-bandwidth *service*. I think
> there is (and
> > has been) general agreement on this.
> >
> > What's not clear to me is if you think there is any requirement for
> > bidirectional asymmetric **LSPs**. Do you have an opinion on this?
> NH=> Well, it depends what you mean by an LSP. As I've tried to point
> out in the past there are very good scientific reasons why we are
> forced to deal with 3 network modes...cl-ps, co-ps and co-cs...and why
> all technologies map to one of these. Moreover the modes are
> fundamentally different...and you cannot apply the same treatment to
> them all. We've done lots of work in explaining this within SG15
> unified modelling based on Information Theory considerations of how
> both the labelling AND resource assignment work in space, freq and
> time dimensions. The space and freq dimensions always force a co-cs
> mode behaviour. However, it is how one slices up the time dimension
> that generates either the (TDM spin of the) co-cs mode or the co-ps
> mode. Without getting into too much detail, when the time slices are
> regular (ie fixed in BOTH start datum AND duration) then labelling
> (which is also implicit) and resource assignment are coupled/fixed and
> the co-cs mode results. However, when the time slices are irregular
> then labelling (which now has to be explicit) and resource assignment
> are decoupled the co-ps mode results.
>
> The co-cs mode is extremely robust to arch misuse. For example, one
> cannot violate the rules of a connection (ie single source, no
> internal routing) in the co-cs mode...and a connection is a crucial
> pre-requiste for all manner of things that one oftens wants
> determinsism on, like OAM and resource assignment per se for SLAs. The
> co-cs mode also has other desirable properties (like must have OOB
> control/management, no QoS classes, etc) which are highly beneficial
> and make networking simple...esp for network builder services (ie
> constructing the topology of other layer networks).
>
> Now the co-ps is not so robust to arch misuse. One can create mp2p
> merging constructs for example, as we find in MPLS. These cannot have
> simple OAM nor can they provide deterministic resource
> assignment/management.
>
> So, when you says LSPs you have to (i) be clear on the network mode
> you are referring to and (ii) if the co-ps mode whether or not the LSP
> respects the requirements of a connection...as not all LSPs do here.
> Aside => One can clearly not construct client layer topoplogy from
> mp2p server layer constructs!
>
> If I am providing (or indeed procuring) a network builder service (ie
> I want to construct the topology of some higher client layer
> network....be this a public service network or indeed a private (VPN)
> network) then I would want 'LSPs' that respect the requirements of a
> connection...because I want to see some strong SLAs associated with
> that service. In the general case these would be based on p2p BW
> symmetric constructs. However, in the case of end-system applications
> supporting specific services like the ones I referred to in my
> response to Igor then the requirement may not indeed be
> symmetric....the p2mp *connection* being a case in point for say TV
> dist (residential) or financial data distribution (business/private).
>
> Not sure if that helps Lou, but its the best I can offer for now.
>
> regards, Neil
>
>
> >
> > (if you already stated this, my apologies that I didn't
> understand you
> > ...)
> >
> > Thanks,
> > Lou
> >
> > At 09:18 AM 4/19/2007, neil.2.harrison@bt.com wrote:
> >
> > >Thanks Igor....I think the answer is context sensitive.
> For example:
> > >
> > >- are we dealing with a client/server network
> > >builder private service?...which may contain a large number of
> > >aggregate end-system client application traffic flows
> > >- are we dealing with a single 'end system to
> > >1st layer network adaptation' service?...which may be a public or
> > >private service
> > >
> > >In the former case, and increasingly so as one moves towards the
> > >duct, there is (of necessity) a lack of detailed information of
> > >higher client BW requirements. So here there is a natural case to
> > >want to provide symmetric BW resources....and the atomic building
> > >block for such services are p2p constructs.
> > >
> > >However, when we look towards specific end-system services
> there is
> > >more scope for BW resource asymmetry.......a video
> streaming service
> > >would probably be like this. Further, it may not be
> simply p2p but
> > >p2mp. I can also imagine some creative thinking wrt to
> using a co-ps
> > >mode with proper p2mp *connections* providing the service in one
> > >direction (ie root to leaves) ....because we want some strong
> > >resource assignment and SLA guarantees, eg distributing financial
> > >information to traders.....but a cl-ps mode return network
> (leaves to
> > >root) providing 'control signals'
> > >(where strong resource assignment may not be so important). The
> > >return direction could however be a set of N p2p connections
> > >(probably congruently routed wrt to the other direction) if strong
> > >resource assignment and SLAs were also required in the return
> > >direction. The former case here could be considered quite
> novel as
> > >the overall service is using 2 network modes and, by definition, 2
> > >different layer networks....so here there is large degree of
> > >asymmetry here.
> > >
> > >So, as one moves towards the duct (and in general for
> network builder
> > >services) there is, IMO, a strong requirement for symmetry in all
> > >aspects, but as one moves towards the application there are cases
> > >where asymmetry is more appropriate.
> > >
> > >regards, Neil
> > >
> > >
> > >-----Original Message-----
> > >From: Igor Bryskin [mailto:i_bryskin@yahoo.com]
> > >Sent: 19 April 2007 13:36
> > >To: Harrison,N,Neil,JCGA1 R;
> > >martin.vigoureux@alcatel-lucent.fr;
> > >Attila.Takacs@ericsson.com; adrian@olddog.co.uk; lberger@labn.net
> > >Cc: ccamp@ops.ietf.org
> > >Subject: RE: Switching technologies requiring bidirectional
> > asymmetric LSPs?
> > >
> > >Neil,
> > >
> > >I consider your input very important to this discussion.
> > >
> > >My question is: Do you see use cases for bidirectional p2p
> services
> > >which are asymmetrical from the bandwidth reservation
> point of view
> > >(that is, in S=>D direction you need bandwidth B1, while in D=>S
> > >direction you need bandwidth B2, and B1 is significantly different
> > >from B2), but fully symmetrical in all other aspects (i.e. routes,
> > >protection capability, etc.)
> > >
> > >Thanks,
> > >Igor
> > >
> > >neil.2.harrison@bt.com wrote:
> > >Thanks Martin,
> > >
> > >Most applications generate asymmetric (wrt time)
> information flows in
> > >each direction, ie the rate of information flow in each
> direction is
> > >neither constant nor directly proportional to the rate of
> information
> > >flow in the other direction....just think about a voice
> conversation
> > >if not obvious....or even a file transfer.
> > >
> > >However, for an arbitrarily meshed network we generally require
> > >symmetric routings of traffic flows, ie if one direction
> passes the
> > >nodes
> > >a->b->c->d in one direction then the other
> > >direction should follow d->c->b->a in both this and lower layer
> > >networks (to the duct).
> > >Moreover, we usually require (under failure free
> > >conditions) that such routings do not change over the
> lifetime of a
> > >traffic flow.......this is particularly important for
> connections (ie
> > >co-ps and co-cs modes), and especially when they are supporting a
> > >network builder service (a VPN if you like), which may be a large
> > >aggregate of all kinds of end-system application traffic
> flows, for
> > >some other party. Note that if we add nodes/links to a co
> mode layer
> > >network we should not change existing connection routings. This is
> > >not always the case with a cl-ps mode network, ie because
> we do not
> > >have connections adding new nodes/links can allow traffic flows to
> > >change routing.
> > >
> > >Is that more clear now wrt what I meant?
> > >
> > >regards, Neil
> > >
> > > > -----Original Message-----
> > > > From: Martin Vigoureux
> [mailto:martin.vigoureux@alcatel-lucent.fr]
> > > > Sent: 19 April 2007 09:37
> > > > To: Harrison,N,Neil,JCGA1 R; Attila.Takacs@ericsson.com;
> > > > i_bryskin@yahoo.com; adrian@olddog.co.uk; lberger@labn.net
> > > > Cc: ccamp@ops.ietf.org
> > > > Subject: Re: Switching technologies requiring bidirectional
> > > > asymmetric LSPs?
> > > >
> > > >
> > > > Neil,
> > > >
> > > > for clarification purposes, the asymmetry I was referring
> > to was in
> > > > terms of bandwidth not path/route or other TE parameter,
> > but maybe I
> > > > did not catch what you meant by *routings*.
> > > >
> > > > regards,
> > > >
> > > > martin
> > > >
> > > > neil.2.harrison@bt.com a écrit :
> > > > > I would caution against the observation that because
> > traffic flows
> > > > > a->b and b->a are invariably asymmetric (wrt resource
> > > > consumed at any
> > > > > epoch) their *routings* can also be asymmetric....this does
> > > > not follow
> > > > > at all. This observation applies to all layer networks (any
> > > > > mode/technology).
> > > > >
> > > > > regards, Neil
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org]
> > > > >> On Behalf Of Martin Vigoureux
> > > > >> Sent: 19 April 2007 08:34
> > > > >> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou
> > > > >> Berger
> > > > >> Cc: ccamp@ops.ietf.org
> > > > >> Subject: Re: Switching technologies requiring bidirectional
> > > > >> asymmetric LSPs?
> > > > >>
> > > > >>
> > > > >> All,
> > > > >>
> > > > >> I do believe in the need for asymmetric bidirectional LSPs.
> > > > >> Traffic is by nature asymmetric (for the vast majority
> > of it at
> > > > >> least). We may argue that the sum of asymmetric
> traffic could
> > > > >> lead to symmetric traffic or that the above statement is
> > > > >> dependent on the network segment we are considering,
> > but it will
> > > > >> remain true and we should definitely capitalize on
> CCAMP prior
> > > > >> work by taking benefit from the advantages of
> > bidirectional LSP
> > > > >> setup.
> > > > >>
> > > > >> Furthermore, I believe we should not restrict the work and
> > > > >> solution to Ethernet technology only.
> > > > >>
> > > > >> martin
> > > > >>
> > > > >> Attila Takacs (IJ/ETH) a écrit :
> > > > >>> Hi all,
> > > > >>> please see inline [at]
> > > > >>> Regards,
> > > > >>> Attila
> > > > >>>
> > > > >>>
> > > > >>
> --------------------------------------------------------------
> > > > >> ----------
> > > > >>> *From:* owner-ccamp@ops.ietf.org
> > > > >> [mailto:owner-ccamp@ops.ietf.org]
> > > > >>> *On Behalf Of *Igor Bryskin
> > > > >>> *Sent:* Tuesday, April 17, 2007 10:19 PM
> > > > >>> *To:* Adrian Farrel; ccamp@ops.ietf.org; Lou Berger
> > > > >>> *Subject:* Re: Switching technologies requiring
> bidirectional
> > > > >>> asymmetric LSPs?
> > > > >>>
> > > > >>> Adrian, Lou
> > > > >>>
> > > > >>> Please,see in line.
> > > > >>>
> > > > >>> */Adrian Farrel /* wrote:
> > > > >>>
> > > > >>> Hi,
> > > > >>>
> > > > >>> I'm a bit surprised that there was no follow-up to
> > Lou's email.
> > > > >>>
> > > > >>> Does silence indicate that this was put to bed in
> > > > Prague and
> > > > >>> no-one is
> > > > >>> interested in these LSPs?
> > > > >>>
> > > > >>> [at] well, as Lou mentioned at least a few of us
> > > > continue an
> > > > >>> offline discussion on the topic.
> > > > >>>
> > > > >>> > So a few of us have been having been discussing the
> > > > >>> asymmetric work
> > > > >>> > presented in Prague and it seems to me we have an open
> > > > >>> question on
> > > > >>> > requirements.
> > > > >>> >
> > > > >>> > It's clear that at least one switching
> > > > technology (i.e.,
> > > > >>> ethernet/PBB-TE)
> > > > >>> > requires support for bidirectional asymmetric LSPs.
> > > > >>>
> > > > >>> Is this clear? I continue to hear talk of service
> > > > >> requirements,
> > > > >>> but not so
> > > > >>> much of how those services are required to be supported.
> > > > >>>
> > > > >>> The benefits I have heard are:
> > > > >>> 1. Fewer control plane messages 2. Ease of enforecement of
> > > > >>> fate-sharing
> > > > >>>
> > > > >>> IB>> Adrian, you enumerated here the benefits of
> > > > >> bidirectional
> > > > >>> LSPs, and BTW you forgot to mention the most
> > > > important one.
> > > > >>> Ethernet OAM is designed, as I understand, on
> > > > >> assumption that
> > > > >>> the trafic takes the same paths in both
> > > > >> directions. So, if we
> > > > >>> want to preserve the Ethernet native OAM (which we
> > > > >> certainly do
> > > > >>> , because this is half of Ethernet functionality)
> > > > >> we must map a
> > > > >>> bidiretcional service on either a single
> > > > >> bidirectional LSP or
> > > > >>> two unidirectional LSPs using the same path. This
> > > > >> is different
> > > > >>> form MPLS where there are no such OAM requirements.
> > > > >>> Lou is talking about asymetrical bi-directional
> > > > >> LSPs, and what
> > > > >>> is not clear (at least for me) whether we need
> > > > >> asymetrical p2p
> > > > >>> Ethernet services.
> > > > >>>
> > > > >>> [at] Adrian's points are related to the single session vs.
> > > > >>> multiple session discussions we had, which is
> > > > >> generally true for
> > > > >>> any bidirectional LSP.
> > > > >>> The bidirectionality of Ethernet comes basically from two
> > > > >>> aspects imho: (1) in any case, as Igor pointed out,
> > > > >> most of the
> > > > >>> CFM functions will only operate properly if there are
> > > > >>> symmetrical paths. (2) on the other hand, if a
> > > > GMPLS LPS is
> > > > >>> essentially a VLAN within which MAC learning is
> > > > >> operating one
> > > > >>> will need symmetric paths in order the learning functions
> > > > >>> properly.
> > > > >>>
> > > > >>> I had the impression that we already converged
> > > > >> before Prague to
> > > > >>> a single remaining question: do we need the
> > > > >>>> asymmetric bw<<
> > > > >>> extension for a single session bidirectional LSP.
> > > > There were
> > > > >>> some possible cases for asymmetric bw LSPs
> > > > mentioned by Don,
> > > > >>> Diego and myself but these seemed not to convince
> everybody.
> > > > >>> Imho we should focus on this question
> > > > not to loop
> > > > >>> into the discussion we had already.
> > > > >>>
> > > > >>> If we agree on that bidirectional services over
> > > > >> Ethernet need
> > > > >>> symmetrical paths than we could conclude that
> > > > using a single
> > > > >>> session to setup the bidirectional LSP would be the
> > > > >> preferred
> > > > >>> way at least over Ethernet. In this case, imho it is quite
> > > > >>> reasonable to assume that asymmetrical services
> > > > >> that require a
> > > > >>> dedicated LSP would also use a single signaling
> > > > exchange to
> > > > >>> setup the LSP, hence there would be a need for the
> > > > >> asymmetric bw
> > > > >>> extension. Following this thinking, the question
> > > > >> turns into the
> > > > >>> aggregation/hierarchy discussion that was bought up
> > > > >> by Dimitri
> > > > >>> earlier. That is, do we have the need of LSPs per
> > > > >> service. My
> > > > >>> two cents: generally not but there are certain
> > > > >> services where it
> > > > >>> is indeed a reasonable assumption, e.g., IPTV or private
> > > > >>> services.
> > > > >>>
> > > > >>> These are significant, but not dramatic, requirements.
> > > > >>>
> > > > >>> > The question is:
> > > > >>> >
> > > > >>> > Is the *requirement* for bidirectional asymmetric LSPs:
> > > > >>> > (a) a technology specific requirement, or
> > > > >>> > (b) one that is common (this is CCAMP after
> > > > >> all!) to multiple
> > > > >>> switching
> > > > >>> > technologies?
> > > > >>>
> > > > >>> CCAMP deals in transport networks. As far as I can
> > > > >> see the service
> > > > >>> requirements would be pretty much the same all transport
> > > > >>> networks and would certainly be applicable to
> packet, L2, and
> > > > >>> TDM (the latter because TDM will be called on to
> support L2).
> > > > >>>
> > > > >>> IB>> See my comment above: there is a differnce
> > > > >> between MPLS and
> > > > >>> Ethernet services. Also there are certainly
> > > > >> differences between
> > > > >>> MPLS and lambda services (use of the same lambda in both
> > > > >>> directions, for example). So each transport
> > > > >> technology may have
> > > > >>> distinct requirements WRT bidirectional services
> > > > >> and connections
> > > > >>> on which the services are mapped.
> > > > >>>
> > > > >>> > Please keep in mind that service requirements
> > > > are not the
> > > > >>> same thing as
> > > > >>> > switching technology requirements. For example,
> > > > >> we have long
> > > > >>> built
> > > > >>> > bidirectional asymmetric services on
> > > > unidirectional MPLS
> > > > >>> LSPs.
> > > > >>>
> > > > >>> Well, exactly!
> > > > >>> Perhaps someone can explain why the Ethernet
> > > > >> hardware is forced
> > > > >>> to require
> > > > >>> bidirectional asymmetric LSPs when MPLS is happy without?
> > > > >>>
> > > > >>> IB>> Again, IMO the answer is to be able to use native
> > > > >>> Ethernet OAM.
> > > > >>>
> > > > >>> Igor
> > > > >>>
> > > > >>> > The answer to this question will help determine
> > > > >> if we should
> > > > >>> have a
> > > > >>> > technology specific solution or a generic CCAMP
> > > > >> solution (as
> > > > >>> well as the
> > > > >>> > complexity of the solution.)
> > > > >>>
> > > > >>> We should not take any action that deliberately
> > > > precludes or
> > > > >>> makes more
> > > > >>> complex the genericisation (is that an American
> > > > >> word?) of the
> > > > >>> solution
> > > > >>> unless there is a significant difference in simplicity of
> > > > >>> solutions.
> > > > >>>
> > > > >>> But we should take no action at all unless there is
> > > > >> some more
> > > > >>> evidence of
> > > > >>> support for this work!
> > > > >>>
> > > > >>> Adrian
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> --------------------------------------------------------------
> > > > >> ----------
> > > > >>> Ahhh...imagining that irresistible "new car" smell?
> Check out
> > > > >>> new cars at Yahoo! Autos.
> > > > >>>
> > > > >>>
> > > > >>
> > > > >> *http://autos.yahoo.com/new_cars.htm
> > > > >>
> > > >
> > l;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3L
> > > > WN
> > > > >>> hcnM->
> > > > >>>
> > > > >>
> > > > >
> > > >
> > >
> > >
> > >
> > >Ahhh...imagining that irresistible "new car" smell?
> > >Check out
> > ><http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new
> _cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdG
FncwRzbGsDbmV3LWNhcnM->new
> >cars at Yahoo! Autos.
>
>
>
>