Subject: Switching technologies requiring bidirectional asymmetric LSPs?

From: Lou Berger <[email-masked]>
Date: Fri, 06 Apr 2007 09:44:38 -0400

All,

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.  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?

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.

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.)

Much thanks,
Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 16 Apr 2007 17:06:22 +0100

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?

> 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

These are significant, but not dramatic, requirements.

> The question is:
> (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).

> 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?

> 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

---

From: "Don Fedyk" <[email-masked]>
Date: Tue, 17 Apr 2007 09:49:30 -0400

Hi Adrian

Lou stated: 
> > 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.
> 
And Adrian asked: 
> Well, exactly!
> Perhaps someone can explain why the Ethernet hardware is 
> forced to require bidirectional asymmetric LSPs when MPLS 
> is happy without?

A clarification. I assume you are asking why Ethernet hardware is
bidirectional?  Hardware is agnostic to the asymmetric BW aspects above
as far as I know. 

Why bidirectional? In the case of Ethernet, Ethernet Bridging Hardware
uses Bidirectional Relays, symmetric spanning trees and optionally
learning (learning requires symmetry and is built into the relay
function). 

We could debate the origins of this etc. But that is not what we are
chartered to do. We should not be asking "How do we change the
technology to fit GMPLS?".    

Regards,
Don

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 17 Apr 2007 13:18:35 -0700 (PDT)

Adrian, Lou

Please,see in line.

Adrian Farrel <[email-masked]> wrote: Hi,

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.

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.

Well, exactly!

IB>> Again, IMO the answer is to be able to use native Ethernet OAM.

Igor

Adrian 

---------------------------------
Ahhh...imagining that irresistible "new car" smell?
 Check outnew cars at Yahoo! Autos.

---

From: "Attila Takacs \(IJ/ETH\)" <[email-masked]>
Date: Wed, 18 Apr 2007 11:44:10 +0200

Hi all,
please see inline [at]
Regards,
Attila

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Igor Bryskin
	Sent: Tuesday, April 17, 2007 10:19 PM
	To: Adrian Farrel; [email-masked]; Lou Berger
	Subject: Re: Switching technologies requiring bidirectional
asymmetric LSPs?

	Adrian, Lou
	
	Please,see in line.
	
	Adrian Farrel <[email-masked]> 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.
		 
		> 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.

		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. 

		> (b) one that is common (this is CCAMP after all!) to
multiple switching 
		
		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.

		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
		
		> 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://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;
_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM
->

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 19 Apr 2007 09:33:53 +0200

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:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Igor Bryskin
>     *Sent:* Tuesday, April 17, 2007 10:19 PM
>     *To:* Adrian Farrel; [email-masked]; Lou Berger
>     *Subject:* Re: Switching technologies requiring bidirectional
>     asymmetric LSPs?
> 
>     Adrian, Lou
> 
>     Please,see in line.
> 
>     */Adrian Farrel <[email-masked]>/* wrote:
> 
>         Hi,
> 
>         [at] well, as Lou mentioned at least a few of us continue an
>         offline discussion on the topic.
>          
>         ethernet/PBB-TE)
>         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. 
>          
>         switching
>         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.
> 
>         same thing as
>     ------------------------------------------------------------------------
>     <http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM->
>

---

From: <[email-masked]>
Date: Thu, 19 Apr 2007 09:25:48 +0100

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Martin Vigoureux
> Sent: 19 April 2007 08:34
> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian Farrel; Lou Berger
> Cc: [email-masked]
> 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
> 
> requirements,
> >         but not so
> bidirectional
> >         a single remaining question: do we need the 
> >>asymmetric bw<<
> >          > switching technology requirements. For example, 
> we have long
> >         built
> >         Perhaps someone can explain why the Ethernet 
> hardware is forced
> >         to require
> >          > 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
> >         complex the genericisation (is that an American 
> word?) of the
> >         solution
> >         But we should take no action at all unless there is 
> some more
> >         evidence of
> >         support for this work!
> > 
> >         Adrian
> > 
> > 
> > 
> > 
> >     
> <http://us.rd.yahoo.com/evt=48245/> *http://autos.yahoo.com/new_cars.htm
> > 
> l;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWN
> > hcnM->
> > 
> 
>

---

From: Martin Vigoureux <[email-masked]>
Date: Thu, 19 Apr 2007 10:36:34 +0200

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

---

From: <[email-masked]>
Date: Thu, 19 Apr 2007 10:12:08 +0100

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

> From: Martin Vigoureux [mailto:[email-masked]] 
> Sent: 19 April 2007 09:37
> To: Harrison,N,Neil,JCGA1 R; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> 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
> 
> > 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
> > 
> >>>         Does silence indicate that this was put to bed in 
> Prague and
> >>>         no-one is
> >>>          > bidirectional asymmetric services on 
> unidirectional MPLS
> >>> LSPs.
> >>>
> >>>         Well, exactly!
> precludes or
> >>>         makes more

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 19 Apr 2007 05:36:04 -0700 (PDT)

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

[email-masked] wrote: Thanks Martin,

regards, Neil

> >>>     */Adrian Farrel /* wrote:
> >>>
> >>>         Hi,
> >>>
> >> *http://autos.yahoo.com/new_cars.htm
> >>

---

From: <[email-masked]>
Date: Thu, 19 Apr 2007 14:18:13 +0100

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:[email-masked]] 
Sent: 19 April 2007 13:36
To: Harrison,N,Neil,JCGA1 R; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Switching technologies requiring bidirectional asymmetric LSPs?

Neil,

Thanks,
Igor

[email-masked] wrote: 

Thanks Martin,

regards, Neil

> l;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWN

  _____  

Ahhh...imagining that irresistible "new car" smell?
Check out new  <http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM-> cars at Yahoo! Autos.

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Apr 2007 10:04:45 -0400

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?

(if you already stated this, my apologies that I didn't understand you ...)

Thanks,
Lou

At 09:18 AM 4/19/2007, [email-masked] wrote:

>-    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
>
>
>To: Harrison,N,Neil,JCGA1 R; 
>[email-masked]; 
>[email-masked]; [email-masked]; [email-masked]
>Cc: [email-masked]
>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
>
>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.
>
>Check out 
><http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM->new 
>cars at Yahoo! Autos.

---

From: <[email-masked]>
Date: Thu, 19 Apr 2007 17:27:51 +0100

Lou Berger asked 19 April 2007 15:05

> **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

> > > 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
> > >
> > > >> 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.
> > > >>
> > > >>> Diego and myself but these seemed not to convince everybody. 
> > > >>> Imho we should focus on this question
> > > not to loop
> > > >>> networks and would certainly be applicable to packet, L2, and 
> > > >>> TDM (the latter because TDM will
> > > >>> Ahhh...imagining that irresistible "new car" smell? Check out 
> > > >>> new cars at Yahoo! Autos.
> > > >>>
> > > >>>
> > > >>
> ><http://us.rd.yahoo.com/evt=48245/*http://autos.yahoo.com/new
_cars.html;_ylc=X3oDMTE1YW1jcXJ2BF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDbmV3LWNhcnM->new

---

From: Lou Berger <[email-masked]>
Date: Thu, 19 Apr 2007 19:37:58 -0400

At 12:27 PM 4/19/2007, [email-masked] wrote:
>[...]
>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.
>[...]

Neil,
         As you know LSP is a technology independent term used in 
MPLS and GMPLS.  The original question (requirement for bidirectional 
asymmetric-bandwidth *TE* LSPs) was intended to identify which 
network modes the WG considered important.  The motivation for the 
question was the discussions on  bidirectional asymmetric-bandwidth 
TE LSPs for co-ps, specifically Ethernet/PBB-TE, see 
draft-takacs-asym-bw-lsp.  Some have asked if we should define a 
mechanisms that supports other co-ps and co-cs technologies.  Others 
have said that we should not define mechanisms for any technology.

Does this help clarify the question?

Lou

PS

>Aside => One can clearly not construct client layer topoplogy from 
>mp2p server layer constructs!

and I'd claim that the current definition of mp2p is cl-ps...

---

From: <[email-masked]>
Date: Fri, 20 Apr 2007 02:47:22 +0100

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

> From: Igor Bryskin [mailto:[email-masked]]
> Sent: 19 April 2007 21:51
> To: Harrison,N,Neil,JCGA1 R; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> 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
>  
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Thursday, April 19, 2007 12:28 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> 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).
> 
> > >To: Harrison,N,Neil,JCGA1 R; [email-masked];
> > > > From: Martin Vigoureux 
> [mailto:[email-masked]]
> everybody.

---

From: "Attila Takacs \(IJ/ETH\)" <[email-masked]>
Date: Fri, 20 Apr 2007 11:32:58 +0200

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! 

> Sent: Thursday, April 19, 2007 10:51 PM
> To: [email-masked]; [email-masked]
> Attila Takacs (IJ/ETH); [email-masked]; [email-masked]
> > 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?
> > (if you already stated this, my apologies that I didn't 
> understand you 
> > ...)
> > 
> > Thanks,
> > Lou
> > 
> > >builder private service?...which may contain a large number of 
> > >aggregate end-system client application traffic flows
> > >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 
> > >(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
> > >
> > >
> > >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
> > >
> 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
> > >direction should follow d->c->b->a in both this and lower layer 
> > >networks (to the duct).
> > >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.
> > >
> > > > >>> 1. Fewer control plane messages 2. Ease of enforecement of 
> > > > >>> fate-sharing
> > > > >>>
> > > > >>> TDM (the latter because TDM will be called on to 
> support L2).
> > > > >>>

---

From: <[email-masked]>
Date: Fri, 20 Apr 2007 10:50:53 +0100

Attila,
PONs are a good example of asymmetry at the edge
Alan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Attila Takacs (IJ/ETH)
Sent: 20 April 2007 10:33
To: Igor Bryskin; Harrison,N,Neil,JCGA1 R; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Switching technologies requiring bidirectional asymmetric LSPs?

Hi Igor, Neil, and all,

Regards,
Attila

> 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
>  
> 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 
> 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.
> 
> 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.  
> 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).
>

---

From: <[email-masked]>
Date: Fri, 20 Apr 2007 11:24:42 +0100

Good point Alan.  I've also managed to discuss this topic briefly this morning with Andy Reid.  He largely agrees with what I have already said, and thinks the signalling should be able to cater for the majority case of symmetric BW/routing as a bi-directional set-up/tear-down operation.....which is the general case for client/server network builder situations, ie construction of a client layer topology.  However, the signalling should also be able to cater for unidirectional set-up when we need to provide asymmetry in BW and/or routing....usually a non-network builder situation, ie no higher layer network topology being constructed.

Hope that helps.

regards, Neil

> From: Mcguire,A,Alan,XGH51 R 
> Sent: 20 April 2007 10:51
> To: [email-masked]; [email-masked]; 
> Harrison,N,Neil,JCGA1 R; [email-masked]
> [email-masked]; [email-masked]
> [mailto:[email-masked]] On Behalf Of Attila Takacs (IJ/ETH)
> [email-masked]; [email-masked]
> I think it is quite useful to have this discussion on 
> networking modes, topology builder services and the relations 
> to GMPLS LSPs. 
> 
> 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
> 
> > Subject: RE: Switching technologies requiring bidirectional 
> asymmetric
> > LSPs?
> > 
> > Neil,
> > 
> bandwidth 
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of [email-masked]
> > Subject: RE: Switching technologies requiring bidirectional 
> asymmetric
> > LSPs?
> > 
> service (ie
> > > > > >> To: Attila Takacs (IJ/ETH); Igor Bryskin; Adrian 
> Farrel; Lou
> > > > > >> Berger
> > > > > >> Cc: [email-masked]
> > > > > >>> form MPLS where there are no such OAM 
> requirements. Lou is 
> > > > > >>> talking about asymetrical bi-directional
> > > > > >> LSPs, and what

---

From: "MEURIC Julien RD-CORE-LAN" <[email-masked]>
Date: Fri, 20 Apr 2007 18:23:15 +0200

Hi all.

I agree with you, Attila. The needs will come from higher network layers near the edge. All the same, there is no intend to modify the existing solution for symmetrical lower layer applications in the core, but only a wish to extend the tools to encompass the bidirectionnal symmetrical case to be used where needed. I would say the most typical use (and current requirement) is Ethernet, but at least any packet-based technology handled by GMPLS could benefit from it.

Have a nice week-end,

Julien

-----Original Message-----

Hi Igor, Neil, and all,

Regards,
Attila

> > [mailto:[email-masked]]
> > > > >>
> > > > >> All,
> > > > >>