[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Switching technologies requiring bidirectional asymmetric LSPs?
Thanks Igor,
Essentially yes. But I would qualify this by context. The closer one gets to the duct the more important it is for p2p constructs to be the atomic building block.....and more generally this is true for a server layer which is used to create the topology of some client layer network. Remember: A link connection at layer N is formed by a trail (end-end network connection) at layer N-1. Those who are not familiar with func arch stuff should try and read my colleague Andy Reid's text book 'Broadband Networking' chapters 3 and 4 as this gives a good intro to func arch concepts. And ideally should also try and look at the more recent work we are doing on unified modelling of networks as we have now sorted out the principles as to why the 3 network modes must exist (I have just written a paper on this which I will probably be publishing later this year in the BT Technology Journal).
One can, in principle, create higher layer topology using p2mp constructs (but not any others, like mp2p or mp2mp) but a 'broadcast at source filter at sink' networking model is not generally an efficient/practical one for topology creation purposes.
When we get to the top of a network stack (ie a layer network directly supporting external applications/services) then this is where one can more usefully apply asymmetry.
regards, Neil
> -----Original Message-----
> From: Igor Bryskin [mailto:IBryskin@advaoptical.com]
> Sent: 19 April 2007 21:51
> To: Harrison,N,Neil,JCGA1 R; 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?
>
>
> 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.
>
>
>
>