Subject: [mpls-tp] a question about transport path layer and transport Service Layer

From: [email-masked]
Date: Mon, 17 Aug 2009 14:18:57 +0800

hi,all
today I  reviewed draft-ietf-mpls-tp-requirement-10, I  see two concepts 
of "transport service layer" and " transport path layer" ， But I can't 
completely  understand them. there are the following red line description 
about the two definition in this draft.
    Transport Path Layer: A (sub-)layer network that provides point-to-
   point or point-to-multipoint transport paths.  It provides
   independent (of the client) OAM when transporting its clients. 
 
    Transport Service Layer: A layer network in which transport paths are
   used to carry a customer's (individual or bundled) service (may be
   point-to-point, point-to-multipoint or multipoint-to-multipoint
   services).

according to its description. for pw layer or MVC layer, is it belong to 
transport path layer or transport service layer? maybe it is belong to 
either transport path layer or transport Service Layer? 
I don't completely understand this two definations.

best regards
liu

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: <[email-masked]>
Date: Mon, 17 Aug 2009 23:54:52 +0100

Liu,

It depends on the context in which the PW is used. I will illustrate by way
of two examples:

If an Ethernet PW is used to carry an E1 which in turn contain nx64K
customer circuits then the Ethernet PW is part of the transport path layer.

If an Ethernet PW is used to directly carry customer traffic (e.g. As part
of a VPLS) then the Ethernet PW is part of the transport service layer.

Ben

On 17/08/2009 07:18, "[email-masked]" <[email-masked]> wrote:

> 
> hi,all 
> today I  reviewed draft-ietf-mpls-tp-requirement-10, I  see two concepts of
> "transport service layer" and " transport path layer" ， But I can't completely
> understand them. there are the following red line description about the two
> definition in this draft.
> transport path layer or transport service layer? maybe it is belong to either
> transport path layer or transport Service Layer?
> ZTE Information Security Notice: The information contained in this mail is
> solely property of the sender's organization. This mail communication is
> confidential. Recipients named above are obligated to maintain secrecy and are
> not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed. If
> you have received this email in error please notify the originator of the
> message. Any views expressed in this message are those of the individual
> sender.

---

From: [email-masked]
Date: Tue, 18 Aug 2009 09:00:44 +0800

ben,
thank you for your explaining. IMO,when pw layer carry a few structure 
traffics,eg. E1,ATM etc. it will be regarded as part of transport path 
layer and only provides point-to-point or point-to-multipoints transports 
path. when pw layer carry customer traffic ,eg. etherent. it will be 
regarded as part of transport service path. and the customer traffic may 
be p2p, p2mp and mp2mp services.

can my understanding be true?

best regards
liu

<[email-masked]> 
2009-08-18 06:54

收件人
<[email-masked]>, <[email-masked]>
抄送

主题
Re: [mpls-tp] a question about transport path layer and transport Service 
Layer

Liu,

It depends on the context in which the PW is used. I will illustrate by 
way
of two examples:

If an Ethernet PW is used to carry an E1 which in turn contain nx64K
customer circuits then the Ethernet PW is part of the transport path 
layer.

Ben

> today I  reviewed draft-ietf-mpls-tp-requirement-10, I  see two concepts 
of
> transport path layer or transport service layer? maybe it is belong to 
either

---

From: <[email-masked]>
Date: Tue, 18 Aug 2009 08:48:21 +0100

Hope it's OK for me to step-in here.....
 
Liu,  I don't think these classifications are very meaningful or useful.  Once upon a time we had 'unwritten rules' (still are unwritten) for the client/server relationships that made practical sense, ie co-cs mode networks sat at the bottom of the stack (so-called L1 networks), co-ps mode networks sat above these (so-called L2 networks) and cl-ps networks sat above these (so-called L3 networks).  The L1/2/3 classification (that originated in the OSI RM) is quite meaningless, ie all networks are always L3, irrespective of their mode.....indeed network mode classification is the only useful classification of network types.
 
Why is this important?
 
Well, firstly the 3 networks modes are for sure not the same....the theory of why this is given in G.800 (unified modelling of networks), but this is obvious anyway just from a practical observation of the networking world around you, or the simple observation that if all 3 modes were the same then IETF would have no need to bother with GMPLS and MPLS and just do everything in IP.
 
Secondly, we should note that a layer network N is composed of layer N nodes and layer N links (between layer N nodes).  The layer N links are end-end connections in a lower layer N-1 network.  The layer N-1 layer network is itself composed of layer N-1 nodes and layer N-1 links......so the layer N-1 links are in turn supported by layer N-2 end-end connections.  This is a recursive arrangement.  And there are no formal rules for how many layer networks can be recursively nested in such a client/server relationship (these are the 'unwritten rules' I noted earlier).
 
There are 2 important limits of this recursion:
 
-    there must always be a top-of-stack layer network present.  This layer network has the critically important job of supporting external message/file/stream application adaptation functions.  Without this top-of-stack layer network present then all lower layer networking serves no purpose at all...please keep that point in mind at all times, it is very important as some folks tend to forget this.  The PSTN (a 64k co-cs mode layer network), the Internet (a cl-ps mode layer network) and the ATM B-ISDN (a co-ps mode layer network) are the only layer networks that have been specified to take on this full message/file/stream external application supporting role.  It is also no coincidence that these layer networks have well specified E-NNIs between operating parties since we need this to support a public service role.
 
-    there must always be a bottom-of-stack layer network present.  This layer network maps (via lexicon encoding) the binary-based symbols of a higher path layer network into the q'ary-based symbols of a physical section layer network where the key function is the modulation of an EM wave on either metallic, optical or radio media.  This layer network is obviously necessary in order that we can send information across geographic distance.
 
Between these 2 top/bottom must-have extremes of layer networks we can have any number of additional 'filler' layer networks stacked in a recursive client/server manner....for example we could have external file over TCP_IP over Ethernet  over PW over MPLS (with N nested sublayers of LSP) over Ethernet over OTN......or indeed any other almost limitless combination you can think of (these are the 'unwritten rules' again).  However, it should be intuitively obvious that the more filler layer networks there are the greater the design/operational configuration complexity (and thus cost) of the total networking scenario.  In other words we should be striving to reduce the number of layer networks that exist between the must-have top-of-stack (external application interfacing) layer network and the bottom-of-stack (EM wave modulating) layer network.
 
Arbitrary client/server stacking of some number M of layer networks is not simply a design/operational cost/complexity concern per se, but it has a performance inheritance issue to consider as well.  That is:
-    the layer N network performance is defined by (i) impairments introduced in the layer N nodes (which can be a function of traffic load if layer N is either cl-ps or co-ps, this is not true if layer N is co-cs) plus (ii) impairments introduced in the layer N links which, by definition, are inherited from the end-end connections in the layer N-1 layer network.
-    since the layer N-1 network is itself composed of layer N-1 nodes and layer N-1 links, it too has exactly the same performance impairment considerations, ie inherent impairments from the layer N-1 nodes (ie due to their traffic load) and inherited impairments on the layer N-1 links for end-end layer N-2 connections
-    this performance inheritance behaviour continues until we reach the real bottom-of-stack section layer, ie where we modulate an EM wave.
 
The reason the above is important is because if I want to design a layer N network I really don't want any uncertainty in the inherited performance impairments from all lower layer networks (some of which I may not own, but simply lease from some other operating party).  Ideally I want to be able to design my layer N network to have performance behaviour (for the SLAs I have with my customers) that is under my control as a function of the network traffic load at layer N.  However, what I have just stated is only possible if all the lower layer networks:
-    use proper single source connections
-    do not have overbooked BW resources.
....and this recursively applies right down to the duct
 
The above is always true for co-cs server mode networks, ie no choice here, these behaviours are forced as a consequence of what defines the co-cs mode....again this harps back to the 'unwritten rules'.  It is never true for cl-ps mode networks.  And it might be true for co-ps mode networks providing they respect the rules of a connection and do not have overbooked resources.....which is of course why we are only allowing proper p2p and p2mp LSP connections in MPLS-TP and cannot have the mp2p LSP constructs that LDP MPLS creates.
 
What I am trying to get across here is that some arbitrary classification of 'transport path' or transport service' layer (or any other naming convention) is meaningless at best...just like the L1/2/3 classification is meaningless.....indeed PWs have turned the old 'unwritten rules' world upside down (so there are no rules any longer)!
 
The only things that really matter are:
-    the network mode under consideration
-    how many layer networks, and which mode types, exist between the (always present) top-of-stack external application interfacing layer network and the bottom-of-stack EM wave modulating layer network........and its not just 'how many' that impact complexity/cost but also what server mode types exist, since these impact performance inheritance considerations.
 
regards, Neil

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: 18 August 2009 02:01
	To: Niven-jenkins,B,Ben,DMF R
	Cc: [email-masked]
	Subject: Re: [mpls-tp] a question about transport path layer and transport Service Layer

	ben, 
	thank you for your explaining. IMO,when pw layer carry a few structure traffics,eg. E1,ATM etc. it will be regarded as part of transport path layer and only provides point-to-point or point-to-multipoints transports path. when pw layer carry customer traffic ,eg. etherent. it will be regarded as part of transport service path. and the customer traffic may be p2p, p2mp and mp2mp services. 

	best regards 
	liu

2009-08-18 06:54 

收件人
<[email-masked]>, <[email-masked]> 
抄送
主题
Re: [mpls-tp] a question about transport path layer and transport Service Layer

	Liu,

	
	
	Ben

---

From: <[email-masked]>
Date: Tue, 18 Aug 2009 11:28:56 +0100

Liu, Thanks...I think I can see your problem...see if this helps:

Every layer network (irrespective of mode) provides a transport function.  Of course, to transfer information across real geographic distance we have to modulate an EM wave...ergo why proper 'transport networks' require a physical bottom-of-stack manifestation.
 
Now, cl-ps networks do not have connections....obviously....so there are no (parent) transport constructs (for the child traffic units) to be considered.  Further, because we don't have parent transport constructs (like connections - which have a precise meaning, but just park that for now)  we cannot take any short-cuts on labelling in the child traffic units.  So cl-ps mode traffic units MUST contain the following labels: an absolute SA label, an absolute DA label, a client PID label.
 
The co-cs mode relates to either space, freq or regular time-slices of resource.  The regular time-slicing is of most interest here as this defines *both* the start epoch and (crucially) the duration of the resource allocated......what this means is that both forwarding-labelling and resource-allocation are coupled actions, and this is what makes the co-cs mode so robust to arch misuse and why is has always been the de-facto transport network solution. The start epoch is the link-only-unique forwarding label.  Further, because we cannot violate the single source rule of a parent connection (vital to have deterministic resource management) we can omit a source label in the child traffic units.  We can also omit the PID client label in the child traffic units IFF the parent connection will only carry a single/same client.    The above means that only p2p and p2mp constructs are possible in the co-cs mode.....we also call such single source parent transport constructs 'connections' because they provide deterministic resource management.  No choice here in fact, this is the way the physics works in the co-cs mode.  It also means there cannot be any load-sensitive performance impairment inheritance issues (as discussed in my previous mail).  But note the short-cuts on child traffic unit labelling that can be sensibly applied because the parent transport constructs MUST obey the single source rules of a connection in the co-cs mode.
 
The co-ps mode decouples (forwarding) labelling and resource assignment, and it is manifested as irregular time-slices of resource.  Here the forwarding label must be explicitly assigned to the child traffic units.  We can still omit the source label in the child traffic units IFF we do not violate the rule of a parent connection, ie single source only.  If you do violate this single source rule (eg MPLS  LDP LSPs or PHP) you have to recover the lost source information some other way.....either as a cl-ps mode client (since as I noted above these traffic units MUST contain an absolute SA label) or as a higher p2p 1-hop degenerate client connection with a label that is unique to the source...which is precisely what a PW label is in MPLS....and this is only technically required because LDP parent mp2p transport constructs are possible in the co-ps mode.
 
Note carefully that it is only the p2p connection transport construct that is truly recursive as a topology building block.  So even though p2mp connections constructs can have deterministic resource management, we cannot use these as a recursive atomic building block of topology.  And clearly we cannot use mp2p or mp2mp constructs as recursive topology building blocks, just like we cannot have deterministic resource management of such.  What this means practically is that if p2mp connection constructs (or even mp2p or mp2mp non-connection constructs) are used they can only appear directly in support of the top-of-stack network that directly supports external message/file/applications....as this top-of-stack layer network MUST always be present in all cases.  
 
Does that help? 
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 18 August 2009 10:13
	To: Harrison,N,Neil,DEY2 R
	Cc: Niven-jenkins,B,Ben,DMF R; [email-masked]
	Subject: RE: [mpls-tp] a question about transport path layer and transport Service Layer

	Neil 
	I am very thankful to your explaining in detail. I completely agree your opinions and advice. but here why I need to provide the problem ? IMO, 
	 because there is a few difference between " transport path layer " and " service transport layer" . for the former ,it only provides P2P and P2MP transport 
	path. whhile for the later, it needs to carry p2p, p2mp and mp2mp customer services, it is the key problem for service transport layer whether to only P2P and 
	P2MP transport path like transport path layer. or it maybe provide p2p,p2mp and mp2p transport path? 
	
	if we choose the last solution, if pw layer is regarded as part of service transport layer. it can need to consider the condition of MP2P transport path too. 
	or else, pw layer is regarded as part of transport path layer. it will only consider both P2P and P2MP transport path. 

	best regards 
	liu 

<[email-masked]> 

2009-08-18 15:48 

收件人
<[email-masked]>, <[email-masked]> 
抄送
<[email-masked]> 
主题
RE: [mpls-tp] a question about transport path layer and transport Service Layer

	  
	Why is this important? 

	  

	  

	  

	  
	regards, Neil 

	ben, 

	best regards 
	liu 

	

2009-08-18 06:54 

收件人

	

	Liu,

	
	
	Ben

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 18 Aug 2009 12:58:12 +0200

Ben,

> If an Ethernet PW is used to carry an E1 which in turn contain nx64K
customer circuits
> then the Ethernet PW is part of the transport path layer. 

Can you describe what you mean with an "Ethernet PW carrying an E1"?

Is the E1 customer signal mapped first into an Etherent VLAN (EVC) and then
the EVC is mapped into a PW and the PW is identified by a PW label within
the LSP?
- In terms of my layer network names, this would be an E1 service is
supported by an EVC laye, the EVC laeyr is supported by a MVC layer and the
MVC layer is supported by a MVP layer. The p2p EVC transport entity is
monitored using Ethernet OAM (Y.1731/802.1ag). The p2p MVC transport entity
is monitored by MPLS-TP OAM. There is a 1:1 relationship between EVC and MVC
transport entities, and there is a n:1 relationship  between MVC and MVP
transport entities.

An alternative could be:
- The E1 customer signal is mapped first into an Etherent VLAN (EVC) and
then the EVC is identified by a PW label within a LSP? I.e. there is no PW
layer, just a PW labels tack entry header.
- In terms of my layer network names, this would be an E1 service is
supported by an EVC layer, the EVC laeyr is supported by a MVP layer. The
p2p EVC transport entity is monitored using Ethernet OAM (Y.1731/802.1ag).
The p2p MVP transport entity is monitored by MPLS-TP OAM. There is a n:1
relationship between EVC and MVP transport entities.

There is yet a third alternative possible:
- The E1 customer signal is mapped first into an Ethernet MAC frame and then
this MAC frame is mapped into a PW and the PW is identified by a PW label
within the LSP?  I.e. there is no EVC layer, just an Ethernet MAC header.
- In terms of my layer network names, this would be an E1 service is
supported by an MVC layer (and its encapsulation includes a MAC header) and
the MVC layer is supported by a MVP layer. The p2p MVC transport entity is
monitored by MPLS-TP OAM. There is a n:1 relationship  between MVC and MVP
transport entities.

In summary your ambiguous description could be assocaited with each of the
following layer stacks in the transport network:
1) EVC -> MVC -> MVP
2) EVC -> MVP
3) MVC -> MVP.

Which one did you have in mind?

> If an Ethernet PW is used to directly carry customer traffic (e.g. As part
of a
> VPLS) then the Ethernet PW is part of the transport service layer.

Similar question for clarification applies here...

VPLS is the MPLS name for an Ethernet VLAN (EVC) supporting E-Tree or E-LAN
customer services. The customer to network relationship can be a 
1) peering relationship or
2) client/server relationship.

In a peering relationship the rmp/mp2mp EVC transport entity terminates in
the customer domain and is commonly owned by the customer and transport
network. 

In a cleint/server relationship the rmp/mp2mp EVC transport entity
terminates in the transport network domain and is fully owned by the
transport network. The customer's VLAN/BSI is mapped into the EVC in the
UNI-N ports. 

The rmp/mp2mp EVC transport entity is in both cases used to carry the
customer service through the transport network. The status/performance of
the service is monitored by means of Ethernet OAM within the EVC.

There are now two alternatives to carry the EVC:
A) EVC is mapped into a PW and PW is mapped into a LSP (EVC is untagged in
PW, PW is idnetified by PW label whitin the LSP).
B) EVC is mapped into a LSP (EVC is identified by a PW label within the LSP;
there is no PW layer).

In my layer terminology you could thus have the following layer stacks
inside the transport network:
A) EVC -> MVC -> MVP
B) EVC -> MVP

Which one did you have in mind?

Note that the answer to the two questions will help me to finally understand
what the meaning is for you of
- "transport path layer" and
- "transport service layer".

For me, the EVC and MVC are both service/channel layers, as the signals in
those layers have a 1:1 relation with the customer service isntances. For
me, the MVP is a tunnel/path layer, as the signals in this layer have a n:1
relation with the service/channel layer signals.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: dinsdag 18 augustus 2009 0:55
To: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] a question about transport path layer and transport
Service Layer

Liu,

Ben

On 17/08/2009 07:18, "[email-masked]" <[email-masked]> wrote:

> 
> hi,all
> today I  reviewed draft-ietf-mpls-tp-requirement-10, I  see two 
> concepts of "transport service layer" and " transport path layer" ， 
> But I can't completely understand them. there are the following red 
> line description about the two definition in this draft.
> according to its description. for pw layer or MVC layer, is it belong 
> to transport path layer or transport service layer? maybe it is belong 
> to either transport path layer or transport Service Layer?
> ZTE Information Security Notice: The information contained in this 
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated to 
> maintain secrecy and are not permitted to disclose the contents of this
communication to others.
> This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they 
> are addressed. If you have received this email in error please notify 
> the originator of the message. Any views expressed in this message are 
> those of the individual sender.

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: [email-masked]
Date: Tue, 18 Aug 2009 17:13:24 +0800

Neil
I am very thankful to your explaining in detail. I completely agree your 
opinions and advice. but here why I need to provide the problem ? IMO,
 because there is a few difference between " transport path layer " and " 
service transport layer" . for the former ,it only provides P2P and P2MP 
transport 
path. whhile for the later, it needs to carry p2p, p2mp and mp2mp customer 
services, it is the key problem for service transport layer whether to 
only P2P and 
P2MP transport path like transport path layer. or it maybe provide 
p2p,p2mp and mp2p transport path?

if we choose the last solution, if pw layer is regarded as part of service 
transport layer. it can need to consider the condition of MP2P transport 
path too. 
or else, pw layer is regarded as part of transport path layer. it will 
only consider both P2P and P2MP transport path.

best regards
liu

<[email-masked]> 
2009-08-18 15:48

收件人
<[email-masked]>, <[email-masked]>
抄送
<[email-masked]>
主题
RE: [mpls-tp] a question about transport path layer and transport Service 
Layer

Liu,  I don't think these classifications are very meaningful or useful. 
Once upon a time we had 'unwritten rules' (still are unwritten) for the 
client/server relationships that made practical sense, ie co-cs mode 
networks sat at the bottom of the stack (so-called L1 networks), co-ps 
mode networks sat above these (so-called L2 networks) and cl-ps networks 
sat above these (so-called L3 networks).  The L1/2/3 classification (that 
originated in the OSI RM) is quite meaningless, ie all networks are always 
L3, irrespective of their mode.....indeed network mode classification is 
the only useful classification of network types.
 
Why is this important?
 
Well, firstly the 3 networks modes are for sure not the same....the theory 
of why this is given in G.800 (unified modelling of networks), but this is 
obvious anyway just from a practical observation of the networking world 
around you, or the simple observation that if all 3 modes were the same 
then IETF would have no need to bother with GMPLS and MPLS and just do 
everything in IP.
 
Secondly, we should note that a layer network N is composed of layer N 
nodes and layer N links (between layer N nodes).  The layer N links are 
end-end connections in a lower layer N-1 network.  The layer N-1 layer 
network is itself composed of layer N-1 nodes and layer N-1 links......so 
the layer N-1 links are in turn supported by layer N-2 end-end 
connections.  This is a recursive arrangement.  And there are no formal 
rules for how many layer networks can be recursively nested in such a 
client/server relationship (these are the 'unwritten rules' I noted 
earlier).

-    there must always be a top-of-stack layer network present.  This 
layer network has the critically important job of supporting external 
message/file/stream application adaptation functions.  Without this 
top-of-stack layer network present then all lower layer networking serves 
no purpose at all...please keep that point in mind at all times, it is 
very important as some folks tend to forget this.  The PSTN (a 64k co-cs 
mode layer network), the Internet (a cl-ps mode layer network) and the ATM 
B-ISDN (a co-ps mode layer network) are the only layer networks that have 
been specified to take on this full message/file/stream external 
application supporting role.  It is also no coincidence that these layer 
networks have well specified E-NNIs between operating parties since we 
need this to support a public service role.
 
-    there must always be a bottom-of-stack layer network present.  This 
layer network maps (via lexicon encoding) the binary-based symbols of a 
higher path layer network into the q'ary-based symbols of a physical 
section layer network where the key function is the modulation of an EM 
wave on either metallic, optical or radio media.  This layer network is 
obviously necessary in order that we can send information across 
geographic distance.
 
Between these 2 top/bottom must-have extremes of layer networks we can 
have any number of additional 'filler' layer networks stacked in a 
recursive client/server manner....for example we could have external file 
over TCP_IP over Ethernet  over PW over MPLS (with N nested sublayers of 
LSP) over Ethernet over OTN......or indeed any other almost limitless 
combination you can think of (these are the 'unwritten rules' again). 
However, it should be intuitively obvious that the more filler layer 
networks there are the greater the design/operational configuration 
complexity (and thus cost) of the total networking scenario.  In other 
words we should be striving to reduce the number of layer networks that 
exist between the must-have top-of-stack (external application 
interfacing) layer network and the bottom-of-stack (EM wave modulating) 
layer network.
 
Arbitrary client/server stacking of some number M of layer networks is not 
simply a design/operational cost/complexity concern per se, but it has a 
performance inheritance issue to consider as well.  That is:
-    the layer N network performance is defined by (i) impairments 
introduced in the layer N nodes (which can be a function of traffic load 
if layer N is either cl-ps or co-ps, this is not true if layer N is co-cs) 
plus (ii) impairments introduced in the layer N links which, by 
definition, are inherited from the end-end connections in the layer N-1 
layer network.
-    since the layer N-1 network is itself composed of layer N-1 nodes and 
layer N-1 links, it too has exactly the same performance impairment 
considerations, ie inherent impairments from the layer N-1 nodes (ie due 
to their traffic load) and inherited impairments on the layer N-1 links 
for end-end layer N-2 connections
-    this performance inheritance behaviour continues until we reach the 
real bottom-of-stack section layer, ie where we modulate an EM wave.
 
The reason the above is important is because if I want to design a layer N 
network I really don't want any uncertainty in the inherited performance 
impairments from all lower layer networks (some of which I may not own, 
but simply lease from some other operating party).  Ideally I want to be 
able to design my layer N network to have performance behaviour (for the 
SLAs I have with my customers) that is under my control as a function of 
the network traffic load at layer N.  However, what I have just stated is 
only possible if all the lower layer networks:
-    use proper single source connections
-    do not have overbooked BW resources.
....and this recursively applies right down to the duct
 
The above is always true for co-cs server mode networks, ie no choice 
here, these behaviours are forced as a consequence of what defines the 
co-cs mode....again this harps back to the 'unwritten rules'.  It is never 
true for cl-ps mode networks.  And it might be true for co-ps mode 
networks providing they respect the rules of a connection and do not have 
overbooked resources.....which is of course why we are only allowing 
proper p2p and p2mp LSP connections in MPLS-TP and cannot have the mp2p 
LSP constructs that LDP MPLS creates.
 
What I am trying to get across here is that some arbitrary classification 
of 'transport path' or transport service' layer (or any other naming 
convention) is meaningless at best...just like the L1/2/3 classification 
is meaningless.....indeed PWs have turned the old 'unwritten rules' world 
upside down (so there are no rules any longer)!
 
The only things that really matter are:
-    the network mode under consideration
-    how many layer networks, and which mode types, exist between the 
(always present) top-of-stack external application interfacing layer 
network and the bottom-of-stack EM wave modulating layer 
network........and its not just 'how many' that impact complexity/cost but 
also what server mode types exist, since these impact performance 
inheritance considerations.
 
regards, Neil

Of [email-masked]

ben, 

best regards 
liu

收件人

主题

Liu,

Ben

of
either
> I don't completely understand this two definations.
intended

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 18 Aug 2009 17:01:15 +0200

Neil,
 
> Now, cl-ps networks do not have connections
 
As discussed many times already, there are layer networks that support co-ps
and cl-ps transport entities. Both transport entity types are managed and
monitored and both can be traffic engineered. As a consequence both types of
transport entities can and are managed in a similar manner.
 
The main difference between the two transport entities is the information
used to decide to which output port or ports on the transport entity a
frame/packet is to be send. co-ps transport entities use the link id and
label value, while cl-ps trnasport entities use the link id, label value and
an inner label value (typically a DA, but it could also be another label).
 
cl-ps transport entities (e.g. VLANs/EVCs) are today in a number of networks
operated with deterministic resource management... i.e. the
traffic-engineered-vlan concept in which each p2p link connection of such
vlan/evc has an enforced CIR and EIR.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: dinsdag 18 augustus 2009 12:29
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] a question about transport path layer and
transportService Layer

Every layer network (irrespective of mode) provides a transport function.
Of course, to transfer information across real geographic distance we have
to modulate an EM wave...ergo why proper 'transport networks' require a
physical bottom-of-stack manifestation.
 
Now, cl-ps networks do not have connections....obviously....so there are no
(parent) transport constructs (for the child traffic units) to be
considered.  Further, because we don't have parent transport constructs
(like connections - which have a precise meaning, but just park that for
now)  we cannot take any short-cuts on labelling in the child traffic units.
So cl-ps mode traffic units MUST contain the following labels: an absolute
SA label, an absolute DA label, a client PID label.
 
The co-cs mode relates to either space, freq or regular time-slices of
resource.  The regular time-slicing is of most interest here as this defines
*both* the start epoch and (crucially) the duration of the resource
allocated......what this means is that both forwarding-labelling and
resource-allocation are coupled actions, and this is what makes the co-cs
mode so robust to arch misuse and why is has always been the de-facto
transport network solution. The start epoch is the link-only-unique
forwarding label.  Further, because we cannot violate the single source rule
of a parent connection (vital to have deterministic resource management) we
can omit a source label in the child traffic units.  We can also omit the
PID client label in the child traffic units IFF the parent connection will
only carry a single/same client.    The above means that only p2p and p2mp
constructs are possible in the co-cs mode.....we also call such single
source parent transport constructs 'connections' because they provide
deterministic resource management.  No choice here in fact, this is the way
the physics works in the co-cs mode.  It also means there cannot be any
load-sensitive performance impairment inheritance issues (as discussed in my
previous mail).  But note the short-cuts on child traffic unit labelling
that can be sensibly applied because the parent transport constructs MUST
obey the single source rules of a connection in the co-cs mode.
 
The co-ps mode decouples (forwarding) labelling and resource assignment, and
it is manifested as irregular time-slices of resource.  Here the forwarding
label must be explicitly assigned to the child traffic units.  We can still
omit the source label in the child traffic units IFF we do not violate the
rule of a parent connection, ie single source only.  If you do violate this
single source rule (eg MPLS  LDP LSPs or PHP) you have to recover the lost
source information some other way.....either as a cl-ps mode client (since
as I noted above these traffic units MUST contain an absolute SA label) or
as a higher p2p 1-hop degenerate client connection with a label that is
unique to the source...which is precisely what a PW label is in MPLS....and
this is only technically required because LDP parent mp2p transport
constructs are possible in the co-ps mode.
 
Note carefully that it is only the p2p connection transport construct that
is truly recursive as a topology building block.  So even though p2mp
connections constructs can have deterministic resource management, we cannot
use these as a recursive atomic building block of topology.  And clearly we
cannot use mp2p or mp2mp constructs as recursive topology building blocks,
just like we cannot have deterministic resource management of such.  What
this means practically is that if p2mp connection constructs (or even mp2p
or mp2mp non-connection constructs) are used they can only appear directly
in support of the top-of-stack network that directly supports external
message/file/applications....as this top-of-stack layer network MUST always
be present in all cases.  
 
Does that help? 
 
regards, Neil

  _____  

Subject: RE: [mpls-tp] a question about transport path layer and transport
Service Layer

Neil 
I am very thankful to your explaining in detail. I completely agree your
opinions and advice. but here why I need to provide the problem ? IMO, 
 because there is a few difference between " transport path layer " and "
service transport layer" . for the former ,it only provides P2P and P2MP
transport 
path. whhile for the later, it needs to carry p2p, p2mp and mp2mp customer
services, it is the key problem for service transport layer whether to only
P2P and 
P2MP transport path like transport path layer. or it maybe provide p2p,p2mp
and mp2p transport path? 

if we choose the last solution, if pw layer is regarded as part of service
transport layer. it can need to consider the condition of MP2P transport
path too. 
or else, pw layer is regarded as part of transport path layer. it will only
consider both P2P and P2MP transport path. 

best regards 
liu 

<[email-masked]> 

2009-08-18 15:48 

收件人

抄送
<[email-masked]> 

主题

Liu,  I don't think these classifications are very meaningful or useful.
Once upon a time we had 'unwritten rules' (still are unwritten) for the
client/server relationships that made practical sense, ie co-cs mode
networks sat at the bottom of the stack (so-called L1 networks), co-ps mode
networks sat above these (so-called L2 networks) and cl-ps networks sat
above these (so-called L3 networks).  The L1/2/3 classification (that
originated in the OSI RM) is quite meaningless, ie all networks are always
L3, irrespective of their mode.....indeed network mode classification is the
only useful classification of network types. 
  
Why is this important? 
  
Well, firstly the 3 networks modes are for sure not the same....the theory
of why this is given in G.800 (unified modelling of networks), but this is
obvious anyway just from a practical observation of the networking world
around you, or the simple observation that if all 3 modes were the same then
IETF would have no need to bother with GMPLS and MPLS and just do everything
in IP. 
  
Secondly, we should note that a layer network N is composed of layer N nodes
and layer N links (between layer N nodes).  The layer N links are end-end
connections in a lower layer N-1 network.  The layer N-1 layer network is
itself composed of layer N-1 nodes and layer N-1 links......so the layer N-1
links are in turn supported by layer N-2 end-end connections.  This is a
recursive arrangement.  And there are no formal rules for how many layer
networks can be recursively nested in such a client/server relationship
(these are the 'unwritten rules' I noted earlier). 

-    there must always be a top-of-stack layer network present.  This layer
network has the critically important job of supporting external
message/file/stream application adaptation functions.  Without this
top-of-stack layer network present then all lower layer networking serves no
purpose at all...please keep that point in mind at all times, it is very
important as some folks tend to forget this.  The PSTN (a 64k co-cs mode
layer network), the Internet (a cl-ps mode layer network) and the ATM B-ISDN
(a co-ps mode layer network) are the only layer networks that have been
specified to take on this full message/file/stream external application
supporting role.  It is also no coincidence that these layer networks have
well specified E-NNIs between operating parties since we need this to
support a public service role. 
  
-    there must always be a bottom-of-stack layer network present.  This
layer network maps (via lexicon encoding) the binary-based symbols of a
higher path layer network into the q'ary-based symbols of a physical section
layer network where the key function is the modulation of an EM wave on
either metallic, optical or radio media.  This layer network is obviously
necessary in order that we can send information across geographic distance. 
  
Between these 2 top/bottom must-have extremes of layer networks we can have
any number of additional 'filler' layer networks stacked in a recursive
client/server manner....for example we could have external file over TCP_IP
over Ethernet  over PW over MPLS (with N nested sublayers of LSP) over
Ethernet over OTN......or indeed any other almost limitless combination you
can think of (these are the 'unwritten rules' again).  However, it should be
intuitively obvious that the more filler layer networks there are the
greater the design/operational configuration complexity (and thus cost) of
the total networking scenario.  In other words we should be striving to
reduce the number of layer networks that exist between the must-have
top-of-stack (external application interfacing) layer network and the
bottom-of-stack (EM wave modulating) layer network. 
  
Arbitrary client/server stacking of some number M of layer networks is not
simply a design/operational cost/complexity concern per se, but it has a
performance inheritance issue to consider as well.  That is: 
-    the layer N network performance is defined by (i) impairments
introduced in the layer N nodes (which can be a function of traffic load if
layer N is either cl-ps or co-ps, this is not true if layer N is co-cs) plus
(ii) impairments introduced in the layer N links which, by definition, are
inherited from the end-end connections in the layer N-1 layer network. 
-    since the layer N-1 network is itself composed of layer N-1 nodes and
layer N-1 links, it too has exactly the same performance impairment
considerations, ie inherent impairments from the layer N-1 nodes (ie due to
their traffic load) and inherited impairments on the layer N-1 links for
end-end layer N-2 connections 
-    this performance inheritance behaviour continues until we reach the
real bottom-of-stack section layer, ie where we modulate an EM wave. 
  
The reason the above is important is because if I want to design a layer N
network I really don't want any uncertainty in the inherited performance
impairments from all lower layer networks (some of which I may not own, but
simply lease from some other operating party).  Ideally I want to be able to
design my layer N network to have performance behaviour (for the SLAs I have
with my customers) that is under my control as a function of the network
traffic load at layer N.  However, what I have just stated is only possible
if all the lower layer networks: 
-    use proper single source connections 
-    do not have overbooked BW resources. 
....and this recursively applies right down to the duct 
  
The above is always true for co-cs server mode networks, ie no choice here,
these behaviours are forced as a consequence of what defines the co-cs
mode....again this harps back to the 'unwritten rules'.  It is never true
for cl-ps mode networks.  And it might be true for co-ps mode networks
providing they respect the rules of a connection and do not have overbooked
resources.....which is of course why we are only allowing proper p2p and
p2mp LSP connections in MPLS-TP and cannot have the mp2p LSP constructs that
LDP MPLS creates. 
  
What I am trying to get across here is that some arbitrary classification of
'transport path' or transport service' layer (or any other naming
convention) is meaningless at best...just like the L1/2/3 classification is
meaningless.....indeed PWs have turned the old 'unwritten rules' world
upside down (so there are no rules any longer)! 
  
The only things that really matter are: 
-    the network mode under consideration 
-    how many layer networks, and which mode types, exist between the
(always present) top-of-stack external application interfacing layer network
and the bottom-of-stack EM wave modulating layer network........and its not
just 'how many' that impact complexity/cost but also what server mode types
exist, since these impact performance inheritance considerations. 
  
regards, Neil 

  _____  

ben, 
thank you for your explaining. IMO,when pw layer carry a few structure
traffics,eg. E1,ATM etc. it will be regarded as part of transport path layer
and only provides point-to-point or point-to-multipoints transports path.
when pw layer carry customer traffic ,eg. etherent. it will be regarded as
part of transport service path. and the customer traffic may be p2p, p2mp
and mp2mp services. 

best regards 
liu 

2009-08-18 06:54 

收件人

抄送

主题

Liu,

Ben

of
either
> I don't completely understand this two definations.
are
> solely for the use of the individual or entity to whom they are addressed.
If
system.

are not permitted to disclose the contents of this communication to others.
If you have received this email in error please notify the originator of the

ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and
are not permitted to disclose the contents of this communication to others.

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the originator of the
message. Any views expressed in this message are those of the individual
sender.

---

From: <[email-masked]>
Date: Tue, 18 Aug 2009 16:24:45 +0100

Thanks Maarten, 
 
If Andy Reid could not help you understand this stuff (despite having produced G.800 to show how the 3 modes differ from going right back to fundamental information theory principles) then I for sure am not going to fare any better.  I think folks can make their own minds up on where we have differences.
 
regards, Neil

	From: Maarten Vissers [mailto:[email-masked]] 
	Sent: 18 August 2009 16:01
	To: Harrison,N,Neil,DEY2 R; [email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] a question about transport path layer and transportService Layer

	Neil,
	 
	> Now, cl-ps networks do not have connections
	 
	As discussed many times already, there are layer networks that support co-ps and cl-ps transport entities. Both transport entity types are managed and monitored and both can be traffic engineered. As a consequence both types of transport entities can and are managed in a similar manner.
	 
	The main difference between the two transport entities is the information used to decide to which output port or ports on the transport entity a frame/packet is to be send. co-ps transport entities use the link id and label value, while cl-ps trnasport entities use the link id, label value and an inner label value (typically a DA, but it could also be another label).
	 
	cl-ps transport entities (e.g. VLANs/EVCs) are today in a number of networks operated with deterministic resource management... i.e. the traffic-engineered-vlan concept in which each p2p link connection of such vlan/evc has an enforced CIR and EIR.
	 
	Regards,
	Maarten

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: dinsdag 18 augustus 2009 12:29
	To: [email-masked]
	Cc: [email-masked]
	Subject: Re: [mpls-tp] a question about transport path layer and transportService Layer

	 

	 
	 
	Does that help? 
	 
	regards, Neil

		Neil 

		
		best regards 
		liu 

<[email-masked]> 

2009-08-18 15:48 

收件人

		  
		Why is this important? 

		  

		  

		  

		  
		regards, Neil 

		ben, 

		best regards 
		liu 

		

2009-08-18 06:54 

收件人

		

		Liu,

		
		
		Ben

---

From: Malcolm Betts <[email-masked]>
Date: Tue, 18 Aug 2009 13:40:27 -0400

All,

I think that both Maarten and Neil are making valid points, but IMHO
they are talking about different things:

If we look at a network (only) from the perspective of configuration
management i.e. which ports at the boundary of a network are allowed to
communicated then the actual mode of communication does not matter.
This is the Transport Entity that Maarten is referring to.

If we now look inside the network at how the traffic units are forwarded
across the network then we can observe the three modes of the network
CO-CS, CO-PS and CL-PS) and we can observe differences in behaviour.
This is why Neil states (correctly) that CL-PS network do not support
connections (in the G.800 traffic forwarding sense).

Regards,

Malcolm

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maarten Vissers
Sent: Tuesday, August 18, 2009 11:01 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] a question about transport path layer and
transportService Layer

Neil,

> Now, cl-ps networks do not have connections

As discussed many times already, there are layer networks that support
co-ps and cl-ps transport entities. Both transport entity types are
managed and monitored and both can be traffic engineered. As a
consequence both types of transport entities can and are managed in a
similar manner.

The main difference between the two transport entities is the
information used to decide to which output port or ports on the
transport entity a frame/packet is to be send. co-ps transport entities
use the link id and label value, while cl-ps trnasport entities use the
link id, label value and an inner label value (typically a DA, but it
could also be another label).

cl-ps transport entities (e.g. VLANs/EVCs) are today in a number of
networks operated with deterministic resource management... i.e. the
traffic-engineered-vlan concept in which each p2p link connection of
such vlan/evc has an enforced CIR and EIR.

Regards,

Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: dinsdag 18 augustus 2009 12:29
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] a question about transport path layer and
transportService Layer

 

Every layer network (irrespective of mode) provides a transport
function.  Of course, to transfer information across real geographic
distance we have to modulate an EM wave...ergo why proper 'transport
networks' require a physical bottom-of-stack manifestation.

Now, cl-ps networks do not have connections....obviously....so there are
no (parent) transport constructs (for the child traffic units) to be
considered.  Further, because we don't have parent transport constructs
(like connections - which have a precise meaning, but just park that for
now)  we cannot take any short-cuts on labelling in the child traffic
units.  So cl-ps mode traffic units MUST contain the following labels:
an absolute SA label, an absolute DA label, a client PID label.

The co-cs mode relates to either space, freq or regular time-slices of
resource.  The regular time-slicing is of most interest here as this
defines *both* the start epoch and (crucially) the duration of the
resource allocated......what this means is that both
forwarding-labelling and resource-allocation are coupled actions, and
this is what makes the co-cs mode so robust to arch misuse and why is
has always been the de-facto transport network solution. The start epoch
is the link-only-unique forwarding label.  Further, because we cannot
violate the single source rule of a parent connection (vital to have
deterministic resource management) we can omit a source label in the
child traffic units.  We can also omit the PID client label in the child
traffic units IFF the parent connection will only carry a single/same
client.    The above means that only p2p and p2mp constructs are
possible in the co-cs mode.....we also call such single source parent
transport constructs 'connections' because they provide deterministic
resource management.  No choice here in fact, this is the way the
physics works in the co-cs mode.  It also means there cannot be any
load-sensitive performance impairment inheritance issues (as discussed
in my previous mail).  But note the short-cuts on child traffic unit
labelling that can be sensibly applied because the parent transport
constructs MUST obey the single source rules of a connection in the
co-cs mode.

The co-ps mode decouples (forwarding) labelling and resource assignment,
and it is manifested as irregular time-slices of resource.  Here the
forwarding label must be explicitly assigned to the child traffic units.
We can still omit the source label in the child traffic units IFF we do
not violate the rule of a parent connection, ie single source only.  If
you do violate this single source rule (eg MPLS  LDP LSPs or PHP) you
have to recover the lost source information some other way.....either as
a cl-ps mode client (since as I noted above these traffic units MUST
contain an absolute SA label) or as a higher p2p 1-hop degenerate client
connection with a label that is unique to the source...which is
precisely what a PW label is in MPLS....and this is only technically
required because LDP parent mp2p transport constructs are possible in
the co-ps mode.

Note carefully that it is only the p2p connection transport construct
that is truly recursive as a topology building block.  So even though
p2mp connections constructs can have deterministic resource management,
we cannot use these as a recursive atomic building block of topology.
And clearly we cannot use mp2p or mp2mp constructs as recursive topology
building blocks, just like we cannot have deterministic resource
management of such.  What this means practically is that if p2mp
connection constructs (or even mp2p or mp2mp non-connection constructs)
are used they can only appear directly in support of the top-of-stack
network that directly supports external message/file/applications....as
this top-of-stack layer network MUST always be present in all cases.  

Does that help? 

regards, Neil

  _____  

Subject: RE: [mpls-tp] a question about transport path layer and
transport Service Layer

Neil 
I am very thankful to your explaining in detail. I completely agree your
opinions and advice. but here why I need to provide the problem ? IMO, 
 because there is a few difference between " transport path layer " and
" service transport layer" . for the former ,it only provides P2P and
P2MP transport 
path. whhile for the later, it needs to carry p2p, p2mp and mp2mp
customer services, it is the key problem for service transport layer
whether to only P2P and 
P2MP transport path like transport path layer. or it maybe provide
p2p,p2mp and mp2p transport path? 

if we choose the last solution, if pw layer is regarded as part of
service transport layer. it can need to consider the condition of MP2P
transport path too. 
or else, pw layer is regarded as part of transport path layer. it will
only consider both P2P and P2MP transport path. 

best regards 
liu 

<[email-masked]> 

2009-08-18 15:48 

收件人

抄送

<[email-masked]> 

主题

RE: [mpls-tp] a question about transport path layer and transport
Service Layer

  
Liu,  I don't think these classifications are very meaningful or useful.
Once upon a time we had 'unwritten rules' (still are unwritten) for the
client/server relationships that made practical sense, ie co-cs mode
networks sat at the bottom of the stack (so-called L1 networks), co-ps
mode networks sat above these (so-called L2 networks) and cl-ps networks
sat above these (so-called L3 networks).  The L1/2/3 classification
(that originated in the OSI RM) is quite meaningless, ie all networks
are always L3, irrespective of their mode.....indeed network mode
classification is the only useful classification of network types. 
  
Why is this important? 
  
Well, firstly the 3 networks modes are for sure not the same....the
theory of why this is given in G.800 (unified modelling of networks),
but this is obvious anyway just from a practical observation of the
networking world around you, or the simple observation that if all 3
modes were the same then IETF would have no need to bother with GMPLS
and MPLS and just do everything in IP. 
  
Secondly, we should note that a layer network N is composed of layer N
nodes and layer N links (between layer N nodes).  The layer N links are
end-end connections in a lower layer N-1 network.  The layer N-1 layer
network is itself composed of layer N-1 nodes and layer N-1
links......so the layer N-1 links are in turn supported by layer N-2
end-end connections.  This is a recursive arrangement.  And there are no
formal rules for how many layer networks can be recursively nested in
such a client/server relationship (these are the 'unwritten rules' I
noted earlier). 

-    there must always be a top-of-stack layer network present.  This
layer network has the critically important job of supporting external
message/file/stream application adaptation functions.  Without this
top-of-stack layer network present then all lower layer networking
serves no purpose at all...please keep that point in mind at all times,
it is very important as some folks tend to forget this.  The PSTN (a 64k
co-cs mode layer network), the Internet (a cl-ps mode layer network) and
the ATM B-ISDN (a co-ps mode layer network) are the only layer networks
that have been specified to take on this full message/file/stream
external application supporting role.  It is also no coincidence that
these layer networks have well specified E-NNIs between operating
parties since we need this to support a public service role. 

Between these 2 top/bottom must-have extremes of layer networks we can
have any number of additional 'filler' layer networks stacked in a
recursive client/server manner....for example we could have external
file over TCP_IP over Ethernet  over PW over MPLS (with N nested
sublayers of LSP) over Ethernet over OTN......or indeed any other almost
limitless combination you can think of (these are the 'unwritten rules'
again).  However, it should be intuitively obvious that the more filler
layer networks there are the greater the design/operational
configuration complexity (and thus cost) of the total networking
scenario.  In other words we should be striving to reduce the number of
layer networks that exist between the must-have top-of-stack (external
application interfacing) layer network and the bottom-of-stack (EM wave
modulating) layer network. 
  
Arbitrary client/server stacking of some number M of layer networks is
not simply a design/operational cost/complexity concern per se, but it
has a performance inheritance issue to consider as well.  That is: 
-    the layer N network performance is defined by (i) impairments
introduced in the layer N nodes (which can be a function of traffic load
if layer N is either cl-ps or co-ps, this is not true if layer N is
co-cs) plus (ii) impairments introduced in the layer N links which, by
definition, are inherited from the end-end connections in the layer N-1
layer network. 
-    since the layer N-1 network is itself composed of layer N-1 nodes
and layer N-1 links, it too has exactly the same performance impairment
considerations, ie inherent impairments from the layer N-1 nodes (ie due
to their traffic load) and inherited impairments on the layer N-1 links
for end-end layer N-2 connections 
-    this performance inheritance behaviour continues until we reach the
real bottom-of-stack section layer, ie where we modulate an EM wave. 
  
The reason the above is important is because if I want to design a layer
N network I really don't want any uncertainty in the inherited
performance impairments from all lower layer networks (some of which I
may not own, but simply lease from some other operating party).  Ideally
I want to be able to design my layer N network to have performance
behaviour (for the SLAs I have with my customers) that is under my
control as a function of the network traffic load at layer N.  However,
what I have just stated is only possible if all the lower layer
networks: 
-    use proper single source connections 
-    do not have overbooked BW resources. 
....and this recursively applies right down to the duct 
  
The above is always true for co-cs server mode networks, ie no choice
here, these behaviours are forced as a consequence of what defines the
co-cs mode....again this harps back to the 'unwritten rules'.  It is
never true for cl-ps mode networks.  And it might be true for co-ps mode
networks providing they respect the rules of a connection and do not
have overbooked resources.....which is of course why we are only
allowing proper p2p and p2mp LSP connections in MPLS-TP and cannot have
the mp2p LSP constructs that LDP MPLS creates. 
  
What I am trying to get across here is that some arbitrary
classification of 'transport path' or transport service' layer (or any
other naming convention) is meaningless at best...just like the L1/2/3
classification is meaningless.....indeed PWs have turned the old
'unwritten rules' world upside down (so there are no rules any longer)! 
  
The only things that really matter are: 
-    the network mode under consideration 
-    how many layer networks, and which mode types, exist between the
(always present) top-of-stack external application interfacing layer
network and the bottom-of-stack EM wave modulating layer network........
and its not just 'how many' that impact complexity/cost but also what
server mode types exist, since these impact performance inheritance
considerations. 
  
regards, Neil 

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: 18 August 2009 02:01
To: Niven-jenkins,B,Ben,DMF R
Cc: [email-masked]
Subject: Re: [mpls-tp] a question about transport path layer and
transport Service Layer

ben, 
thank you for your explaining. IMO,when pw layer carry a few structure
traffics,eg. E1,ATM etc. it will be regarded as part of transport path
layer and only provides point-to-point or point-to-multipoints
transports path. when pw layer carry customer traffic ,eg. etherent. it
will be regarded as part of transport service path. and the customer
traffic may be p2p, p2mp and mp2mp services. 

best regards 
liu 

2009-08-18 06:54 

收件人

抄送

主题

Re: [mpls-tp] a question about transport path layer and transport
Service Layer

Liu,

If an Ethernet PW is used to directly carry customer traffic (e.g. As
part
of a VPLS) then the Ethernet PW is part of the transport service layer.

Ben

> today I  reviewed draft-ietf-mpls-tp-requirement-10, I  see two
concepts of
> according to its description. for pw layer or MVC layer, is it belong
to
either
> I don't completely understand this two definations.
mail is
intended
system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail
is solely property of the sender's organization. This mail communication
is confidential. Recipients named above are obligated to maintain
secrecy and are not permitted to disclose the contents of this
communication to others.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
originator of the message. Any views expressed in this message are those
of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail
is solely property of the sender's organization. This mail communication
is confidential. Recipients named above are obligated to maintain
secrecy and are not permitted to disclose the contents of this
communication to others.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
originator of the message. Any views expressed in this message are those
of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.

---

From: <[email-masked]>
Date: Tue, 18 Aug 2009 18:58:57 +0100

Many thanks Malcolm for your (as usual) wise intervention and accurate observations.  It's so tempting now to elaborate and explain why we must start with the G.800 perspective, but I'll bite my tongue.
 
regards, Neil  

	From: Malcolm Betts [mailto:[email-masked]] 
	Sent: 18 August 2009 18:40
	To: 'Maarten Vissers'; Harrison,N,Neil,DEY2 R; [email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] a question about transport path layer and transportService Layer

	All,

	I think that both Maarten and Neil are making valid points, but IMHO they are talking about different things:

	If we look at a network (only) from the perspective of configuration management i.e. which ports at the boundary of a network are allowed to communicated then the actual mode of communication does not matter.  This is the Transport Entity that Maarten is referring to.

	If we now look inside the network at how the traffic units are forwarded across the network then we can observe the three modes of the network CO-CS, CO-PS and CL-PS) and we can observe differences in behaviour.  This is why Neil states (correctly) that CL-PS network do not support connections (in the G.800 traffic forwarding sense).

	Regards,

	Malcolm

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
	Sent: Tuesday, August 18, 2009 11:01 AM
	To: [email-masked]; [email-masked]
	Cc: [email-masked]
	Subject: Re: [mpls-tp] a question about transport path layer and transportService Layer

	Neil,

	Regards,

	Maarten

	 

	Does that help? 

	regards, Neil

		Neil 

		
		best regards 
		liu 

		

<[email-masked]> 

2009-08-18 15:48 

收件人

抄送

<[email-masked]> 

主题

		

		

		Why is this important? 

		  

		  

		  

		  
		regards, Neil 

		ben, 

		best regards 
		liu 

		

2009-08-18 06:54 

收件人

抄送

主题

		

		Liu,

		
		
		Ben

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 18 Aug 2009 20:08:52 +0200

Neil,
 
The initial version of G.800 had forgotten to include the "transport
entity". This "transport entity" has only been introduced in amendment 1 of
G.800. The impact of this introduction of "transport entity" into G.800 and
the relationship to the "forwarding relationship" will be a subject of
discussion in the upcoming SG15 meeting. The initial version of G.800 could
as such never be a reference for any of the transport network technologies
(all those technologies have been specified around their transport
entities). Having analyzed co-cs, co-ps and cl-ps transport network
technologies for their "transport entity" to "forwarding relationship"
relations, we found the following:
 
1) in some cases the "transport entity" has a 1-to-1 relation with a
"forwarding relationship"; example: 
- p2p SDH VC-12 connection is administered by one forwarding relationship
<input port, input label, output port, output label> 
- p2p Ethernet VLAN connection is administered by one forwarding
relationship <vlan id, port 1, port 2>
 
2) in some cases the "transport enitty" has a 1-to-n relation with a
"forwarding relationship"; example: 
- p2mp SDH VC-12 connection is administered by n forwarding relationships
<input port, input label, output port 1, output label 1>, <input port, input
label, output port 2, output label 2>, .., <input port, input label, output
port n, output label n>
- mp2mp Ethernet VLAN transport entity is administered by n forwarding
relationships <vlan id, port 1, port 2, .., port m>, <vlan id, da A, output
port A>,  <vlan id, da B, output port B>,  etc, <vlan id, da X, output port
X1, X2, X3, ..., Xn>,  <vlan id, da Y, output port Y1, Y2, .., Yn>, ...etc
 
3) in some cases n "transport entity"s have a n-to-1 relation with a
forwarding relationship; example:
- a set of n p2p PBB-TE ESP connections is administered by one forwarding
relationship <esp-vid, esp-da, output port>
 
I hope you understand that it will take some time to enhance G.800 in such a
manner that it can become a reference document for transport network
technology specifications.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 18 augustus 2009 17:25
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] a question about transport path layer and
transportService Layer

Thanks Maarten, 
 
If Andy Reid could not help you understand this stuff (despite having
produced G.800 to show how the 3 modes differ from going right back to
fundamental information theory principles) then I for sure am not going to
fare any better.  I think folks can make their own minds up on where we have
differences.
 
regards, Neil

  _____  

Neil,

 

Regards,
Maarten

  _____  

 

 
 
Does that help? 
 
regards, Neil

  _____  

Neil 

best regards 
liu 

<[email-masked]> 

2009-08-18 15:48 

收件人

抄送
<[email-masked]> 

主题

  
Why is this important? 

  

  

  

  
regards, Neil 

  _____  

ben, 

best regards 
liu 

2009-08-18 06:54 

收件人

抄送

主题

Liu,

Ben

of
either
are
If
system.

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 18 Aug 2009 20:41:12 +0200

Malcolm,
 
It seems that we have to differentiate between
 
1) transport entities, i.e.
    - connection-oriented ones referred to as: trails,
network/subnetwork/tandem/link/seriial-compound-link connections, and
    - connectionless ones referred to as: connectionless trails,
netowrk/subnetwork/tandem/link/serial-compound-link "flow domain fragments"
 
and
 
2) forwarding relationships (i.e. the G.800 traffic forwarding things), i.e.
    - channel forwarding relationship (is this Neil's "connection"? ), and
    - destination forwarding relationship (is this also Neil's
"connection"?).
 
As argued in my previous reply to Neil's email, transport entities and
forwarding relationships are different abstract constructs. They are not
equivalent, but it is possible to describe a number of possible relations
(1:1, n:1, 1:n) between these two abstract constructs.
 
The functional architecture of transport networks is specified around their
transport entities; I have been referring to this as a "macro level
specification".
 
The actual contorl of forwarding of traffic units within their transport
entities, or the actual control of forwarding of trafifc units of multiple
transport entities has been found irrelevant in the functional architecture
of transport networks; I have been referring to this actual forwarding
control as a "micro level specification". It is below the radar screen of
the functional architecture. But that does not make it unimportant.
 
The configuration of transport entities (one type of forwarding
relationships), or groups of transport entities (another type of forwarding
relationships) and the configuration of forwarding and/or filtering rules
within a transport entity (a third type of forwarding relationships) are
subject to connection management. Connection management uses the topological
model of the transport network as its basis (instead of the functional
model). The functional model of a transport network can be transformed in a
well defined manner into a topological model.
 
It would be very helpful if you can help to disentangle the confusion
between the functional (me) and topological (Neil?) model views and
contributions. Such would allow us to progress the development of both the
functional and topological models of MPLS-TP in good harmony, and without
lengthy "yes/no" type discussions.
 
Thanks for your help,
Maarten

  _____  

From: Malcolm Betts [mailto:[email-masked]] 
Sent: dinsdag 18 augustus 2009 19:40
To: 'Maarten Vissers'; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [mpls-tp] a question about transport path layer and
transportService Layer

All,

I think that both Maarten and Neil are making valid points, but IMHO they
are talking about different things:

If we look at a network (only) from the perspective of configuration
management i.e. which ports at the boundary of a network are allowed to
communicated then the actual mode of communication does not matter.  This is
the Transport Entity that Maarten is referring to.

If we now look inside the network at how the traffic units are forwarded
across the network then we can observe the three modes of the network CO-CS,
CO-PS and CL-PS) and we can observe differences in behaviour.  This is why
Neil states (correctly) that CL-PS network do not support connections (in
the G.800 traffic forwarding sense).

Regards,

Malcolm

Of Maarten Vissers

Neil,

Regards,

Maarten

  _____  

 

Does that help? 

regards, Neil

  _____  

Neil 

best regards 
liu 

<[email-masked]> 

2009-08-18 15:48 

收件人

抄送

<[email-masked]> 

主题

		

  
Why is this important? 

  

  

  

  
regards, Neil 

  _____  

ben, 

best regards 
liu 

2009-08-18 06:54 

收件人

抄送

主题

		

Liu,

Ben

of
either
are
If
system.

---

From: [email-masked]
Date: Wed, 19 Aug 2009 10:27:14 +0800

Neil
thanks a lot for your explaining in details. I have completely understood 
what you meaned. but if transport entities only provide P2P and P2MP 
transport path. how about carrying MP2P or MP2MP services in transport 
layer network?  whether these MP2P or MP2MP services will be divided into 
n duplications,then they will be transported by n p2p or p2mp transport 
paths?

best regards
liu

<[email-masked]> 
2009-08-18 18:28

收件人
<[email-masked]>
抄送
<[email-masked]>, <[email-masked]>
主题
RE: [mpls-tp] a question about transport path layer and transport Service 
Layer

 
Now, cl-ps networks do not have connections....obviously....so there are 
no (parent) transport constructs (for the child traffic units) to be 
considered.  Further, because we don't have parent transport constructs 
(like connections - which have a precise meaning, but just park that for 
now)  we cannot take any short-cuts on labelling in the child traffic 
units.  So cl-ps mode traffic units MUST contain the following labels: an 
absolute SA label, an absolute DA label, a client PID label.
 
The co-cs mode relates to either space, freq or regular time-slices of 
resource.  The regular time-slicing is of most interest here as this 
defines *both* the start epoch and (crucially) the duration of the 
resource allocated......what this means is that both forwarding-labelling 
and resource-allocation are coupled actions, and this is what makes the 
co-cs mode so robust to arch misuse and why is has always been the 
de-facto transport network solution. The start epoch is the 
link-only-unique forwarding label.  Further, because we cannot violate the 
single source rule of a parent connection (vital to have deterministic 
resource management) we can omit a source label in the child traffic 
units.  We can also omit the PID client label in the child traffic units 
IFF the parent connection will only carry a single/same client.    The 
above means that only p2p and p2mp constructs are possible in the co-cs 
mode.....we also call such single source parent transport constructs 
'connections' because they provide deterministic resource management.  No 
choice here in fact, this is the way the physics works in the co-cs mode. 
It also means there cannot be any load-sensitive performance impairment 
inheritance issues (as discussed in my previous mail).  But note the 
short-cuts on child traffic unit labelling that can be sensibly applied 
because the parent transport constructs MUST obey the single source rules 
of a connection in the co-cs mode.
 
The co-ps mode decouples (forwarding) labelling and resource assignment, 
and it is manifested as irregular time-slices of resource.  Here the 
forwarding label must be explicitly assigned to the child traffic units. 
We can still omit the source label in the child traffic units IFF we do 
not violate the rule of a parent connection, ie single source only.  If 
you do violate this single source rule (eg MPLS  LDP LSPs or PHP) you have 
to recover the lost source information some other way.....either as a 
cl-ps mode client (since as I noted above these traffic units MUST contain 
an absolute SA label) or as a higher p2p 1-hop degenerate client 
connection with a label that is unique to the source...which is precisely 
what a PW label is in MPLS....and this is only technically required 
because LDP parent mp2p transport constructs are possible in the co-ps 
mode.
 
Note carefully that it is only the p2p connection transport construct that 
is truly recursive as a topology building block.  So even though p2mp 
connections constructs can have deterministic resource management, we 
cannot use these as a recursive atomic building block of topology.  And 
clearly we cannot use mp2p or mp2mp constructs as recursive topology 
building blocks, just like we cannot have deterministic resource 
management of such.  What this means practically is that if p2mp 
connection constructs (or even mp2p or mp2mp non-connection constructs) 
are used they can only appear directly in support of the top-of-stack 
network that directly supports external message/file/applications....as 
this top-of-stack layer network MUST always be present in all cases. 
 
Does that help? 
 
regards, Neil

Neil 

best regards 
liu 

<[email-masked]> 
2009-08-18 15:48 

收件人

  
Why is this important? 

  

  

  

  
regards, Neil 

ben, 

best regards 
liu 

收件人

主题

Liu,

Ben

of
either
> I don't completely understand this two definations.
is
intended
system.

---

From: <[email-masked]>
Date: Wed, 19 Aug 2009 07:38:19 +0100

Thanks Liu,
 
The issue simply boils down to 2 things:
 
-    only p2p constructs are recursive topologically.
 
-    if one wants the traffic behaviour of client X not to impact the SLA/performance experienced by client Y then you really have no choice but to:
    o use proper server connections, ie single source
    o do not overbook server layer resource
....and this applies to every lower layer network down to the duct.
 
The co-cs mode is forced to behave like this.  And the whole point of MPLS-TP is emulate the co-cs mode because the above are a key requirement of a transport network IMO.
 
If one wants to create mp2mp and mp2p constructs in the (one below the real) top-of-stack layer network then fine (but see important aside below), but the server layers under these need to obey the rules I noted above, else there is no resource determinism for the clients.  As more and more major customers require service compliance with ITIL principles then IMO it will become increasingly important for operators to be able to prove determinism of service (which implies determinism of resource).
 
Aside=> One can create mp2mp and mp2p constructs in a non top-of-stack layer network (eg Ethernet, MPLS) *providing*:
-    one does not care too strongly about service/resource assurance AND
-    the real top-of-stack network directly above these constructs is cl-ps in mode, ie one can see an absolute SA, else we have no means to recover the loss of source information AND
-    the real top-of-stack layer network supports the critical message/file/stream application adaptation functions......you may recognise the important layer network that I am talking about here, it is IP.   As I have noted many times now, a real top-of-stack layer network that supports external message/file/stream applications MUST be present else all lower layer networking serves no purpose whatsoever. 
 
regards, Neil

	Sent: 19 August 2009 03:27

	Neil 
	thanks a lot for your explaining in details. I have completely understood what you meaned. but if transport entities only provide P2P and P2MP transport path. how about carrying MP2P or MP2MP services in transport layer network?  whether these MP2P or MP2MP services will be divided into n duplications,then they will be transported by n p2p or p2mp transport paths? 

	best regards 
	liu 

<[email-masked]> 

2009-08-18 18:28 

收件人
<[email-masked]> 
抄送

	  

	  
	  
	Does that help? 
	  
	regards, Neil 

	Neil 

	
	best regards 
	liu 

	
<[email-masked]> 

2009-08-18 15:48 

收件人

	

	 
	Why is this important? 

	 

	 

	 

	 
	regards, Neil 

	ben, 

	best regards 
	liu 

	

2009-08-18 06:54 

收件人

	

	Liu,

	
	
	Ben

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 19 Aug 2009 09:10:00 +0200

Neil,
 
-    if one wants the traffic behaviour of client X not to impact the
SLA/performance experienced by client Y then you really have no choice but
to:
    o use proper server connections, ie single source
    o do not overbook server layer resource
 
You are missing one very important additional means to support this
requirement also for clients that want to be supported by a rmp or mp2mp
server transport entity, i.e. with multiple sources... i.e. the rmp or mp2mp
server transport entity supporting client X and the one supporting client Y
contain a number of p2p link connections, which are interconnected by rmp or
mp2mp matrix transport entities. Each of those server link connections is
traffic engineered and has an enforced CIR/EIR. With this traffic-engineered
rmp/mp2mp transport entity architecture you have guaranteed that the traffic
behaviour of client X does not impact the SLA/performance experienced by
client Y. This architecture is the basis for an open wholesale model for
braodband backhaul that is build on the use of E-Tree (rmp) services.
 
This traffic engineered rmp/mp2mp transport entity architecture is the
reason why I require that the transport entities in the tunnel/path layer
must be p2p connections. But the transport entities in the servcie/channel
layer can be p2p, p2mp, rmp, mp2mp traffic engineered transport entities
supporting clients that demand either a Line (p2p), Tree (p2mp, rmp) or LAN
(mp2mp) service.
 
Regards,
Maarten

  _____  

Sent: woensdag 19 augustus 2009 8:38

Thanks Liu,

 
-    if one wants the traffic behaviour of client X not to impact the
SLA/performance experienced by client Y then you really have no choice but
to:
    o use proper server connections, ie single source
    o do not overbook server layer resource
....and this applies to every lower layer network down to the duct.
 
The co-cs mode is forced to behave like this.  And the whole point of
MPLS-TP is emulate the co-cs mode because the above are a key requirement of
a transport network IMO.
 
If one wants to create mp2mp and mp2p constructs in the (one below the real)
top-of-stack layer network then fine (but see important aside below), but
the server layers under these need to obey the rules I noted above, else
there is no resource determinism for the clients.  As more and more major
customers require service compliance with ITIL principles then IMO it will
become increasingly important for operators to be able to prove determinism
of service (which implies determinism of resource).
 
Aside=> One can create mp2mp and mp2p constructs in a non top-of-stack layer
network (eg Ethernet, MPLS) *providing*:
-    one does not care too strongly about service/resource assurance AND
-    the real top-of-stack network directly above these constructs is cl-ps
in mode, ie one can see an absolute SA, else we have no means to recover the
loss of source information AND
-    the real top-of-stack layer network supports the critical
message/file/stream application adaptation functions......you may recognise
the important layer network that I am talking about here, it is IP.   As I
have noted many times now, a real top-of-stack layer network that supports
external message/file/stream applications MUST be present else all lower
layer networking serves no purpose whatsoever. 
 
regards, Neil

  _____  

Neil 
thanks a lot for your explaining in details. I have completely understood
what you meaned. but if transport entities only provide P2P and P2MP
transport path. how about carrying MP2P or MP2MP services in transport layer
network?  whether these MP2P or MP2MP services will be divided into n
duplications,then they will be transported by n p2p or p2mp transport paths?

best regards 
liu 

<[email-masked]> 

2009-08-18 18:28 

收件人
<[email-masked]> 

抄送

主题

  

  
  
Does that help? 
  
regards, Neil 

  _____  

Neil 

best regards 
liu 

<[email-masked]> 

2009-08-18 15:48 

收件人

抄送
<[email-masked]> 

主题

 
 
Why is this important? 

 

 

 

 
regards, Neil 

  _____  

ben, 

best regards 
liu 

2009-08-18 06:54 

收件人

抄送

主题

Liu,

Ben

of
either
are
If
system.

---

From: [email-masked]
Date: Wed, 19 Aug 2009 15:35:57 +0800

Maarten
according to your reply and explaining. if we will regard PW layer or MVC 
layer as part of service transport layer. then this layer need to provider 
MP2P OR MP2MP transport entities. now it is the key problem to whether to 
provide MP2P or MP2MP transports path for pw layer in MPLS-TP.
can you describles your opinions clearly?  thank you.

best regards
liu

Maarten Vissers <[email-masked]> 
2009-08-19 15:10

收件人
[email-masked], [email-masked]
抄送
[email-masked]
主题
RE: [mpls-tp] a question about transport path layer and transportService 
Layer

Neil,

You are missing one very important additional means to support this 
requirement also for clients that want to be supported by a rmp or mp2mp 
server transport entity, i.e. with multiple sources... i.e. the rmp or 
mp2mp server transport entity supporting client X and the one supporting 
client Y contain a number of p2p link connections, which are 
interconnected by rmp or mp2mp matrix transport entities. Each of those 
server link connections is traffic engineered and has an enforced CIR/EIR. 
With this traffic-engineered rmp/mp2mp transport entity architecture you 
have guaranteed that the traffic behaviour of client X does not impact the 
SLA/performance experienced by client Y. This architecture is the basis 
for an open wholesale model for braodband backhaul that is build on the 
use of E-Tree (rmp) services.
 
supporting clients that demand either a Line (p2p), Tree (p2mp, rmp) or 
LAN (mp2mp) service.
 
Regards,
Maarten

Thanks Liu,

 
 
The co-cs mode is forced to behave like this.  And the whole point of 
MPLS-TP is emulate the co-cs mode because the above are a key requirement 
of a transport network IMO.
 
If one wants to create mp2mp and mp2p constructs in the (one below the 
real) top-of-stack layer network then fine (but see important aside 
below), but the server layers under these need to obey the rules I noted 
above, else there is no resource determinism for the clients.  As more and 
more major customers require service compliance with ITIL principles then 
IMO it will become increasingly important for operators to be able to 
prove determinism of service (which implies determinism of resource).
 
Aside=> One can create mp2mp and mp2p constructs in a non top-of-stack 
layer network (eg Ethernet, MPLS) *providing*:
-    one does not care too strongly about service/resource assurance AND
-    the real top-of-stack network directly above these constructs is 
cl-ps in mode, ie one can see an absolute SA, else we have no means to 
recover the loss of source information AND
-    the real top-of-stack layer network supports the critical 
message/file/stream application adaptation functions......you may 
recognise the important layer network that I am talking about here, it is 
IP.   As I have noted many times now, a real top-of-stack layer network 
that supports external message/file/stream applications MUST be present 
else all lower layer networking serves no purpose whatsoever. 
 
regards, Neil

Neil 

best regards 
liu 

<[email-masked]> 
2009-08-18 18:28 

收件人
<[email-masked]> 
抄送

  

  
  
Does that help? 
  
regards, Neil 

Neil 

best regards 
liu 

<[email-masked]> 
2009-08-18 15:48 

收件人

 
Why is this important? 

 

 

 

 
regards, Neil 

ben, 

best regards 
liu 

收件人

主题

Liu,

Ben

of
either
is
intended
system.

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 19 Aug 2009 10:56:38 +0200

Liu,
 
The service transport/channel layer needs to provide RMP and MP2MP transport
entities in addition to the P2P and P2MP transport entities. 
As we all know, the MVC/PW layer is not capable to support those RMP and
MP2MP transport entities. 
Therefore we add the EVC/VLAN/VPLS layer to the layer stack to support those
RMP and MP2MP transport entities.
 
There are now two alternatives for the transport service/channel layer in a
MPLS-TP based packet transport network:
1) combination of EVC + MVC (see slide 2)
2) EVC only (see slide 3).
 
Add 1) in the EVC + MVC case, the P2P and P2MP transport entities are
supported by the MVC layer and the RMP and MP2MP transport entities are
supported by the EVC layer. The P2P EVC link connections are supported by
the MVC layer.
 
Add 2) in the EVC only case, there is still a PW label stack entry header
but there is no MVC layer and thus no PW OAM. The PW labels tack entry
header acts as EVC Tag and supports a 20-bit EVC ID and a 3-bit EVC PCP (but
there is no EVC DEI).
 
Some operators have decided that there is no real need for an MVC layer in
the layer stack, as the EVC layer can support P2P, P2MP, RMP and MP2MP
transport entities. Other operators have decided that they would like to use
the MVC layer to support P2P and P2MP transport entities and have on top of
this MVC layer the EVC layer to support RMP and MP2MP transport entities.
 
Both approaches will do the job. As equipment vendors we have to support
both approaches in our designs, plus we have to support the all ethernet
approach with and EVP layer instead of a MVP layer (i.e. EVC -> EVP -> EVS
-> ETY layer stack).
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 19 augustus 2009 9:36
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] a question about transport path layer and
transportService Layer

Maarten 

best regards 
liu

2009-08-19 15:10 

收件人

抄送
[email-masked] 

主题

Neil, 

  
  
Regards, 
Maarten 

  _____  

Thanks Liu, 

  

  
  
regards, Neil 

  _____  

Neil 

best regards 
liu 

<[email-masked]> 

2009-08-18 18:28 

收件人
<[email-masked]> 

抄送

主题

 

 
 
Does that help? 
 
regards, Neil 

  _____  

Neil 

best regards 
liu 

<[email-masked]> 

2009-08-18 15:48 

收件人

抄送
<[email-masked]> 

主题

Why is this important? 

regards, Neil 

  _____  

ben, 

best regards 
liu 

2009-08-18 06:54 

收件人

抄送

主题

Liu,

Ben

of
either
are
If
system.

---

From: <[email-masked]>
Date: Wed, 19 Aug 2009 13:48:04 +0100

Thanks Maarten,
 
I do find it a little odd that you demand proper server layer connections at the 'path layer' (which is actually a meaningless concept in a generic client/server sense) in order to provide deterministic resources to your mp2p/mp2mp 'transport entities' that lie above this.  Sounds like 'one rule for me and another rule for everyone else'.
 
Still, at least you tacitly acknowledge here that the mp2p/mp2mp transport entities are a one-trick pony that can only appear once next to the real top-of-stack layer network (eg IP) and demand proper connections under them.  So that is some progress.
 
But let's have a closer look at the mathematical traffic properties of these mp2p transport constructs compared to proper p2p and p2mp connections.
 
If I have a proper single source p2p or p2mp connection then all downstream links towards the sink see exactly the same traffic statistics at all network distances, ie all downstream links see the same peak/mean variance of a *single* source.  We can now do CAC on the link connections to place such proper connections and thus can ensure adequate resources are allocated across a large population of different connections (Aside => I'd advise CIR=PIR for strong resource isolation between different clients, but we can relax this if traffic units are marked as 'excess of CIR').
 
If I have a mp2p construct however, then I do not have the statistical peak/mean traffic variance of a single source on all downstream links but a distance-varying aggregate of different sources, ie an increasing number of different sources are aggregated on different links with increasing distance towards the sink.  In addition to the peak/mean  variance of each individual source I also need to consider the temporal correlation of the different sources (eg sources related to opening/closing times of financial markets are rather different to a set of independent traffic sources).  Further, if sources can join/leave the aggregate and/or change their original temporal correlations over time, then this further increases the uncertainty on all downstream links.  And this is only for a *single* client mp2p service instance!
 
So if I have M such mp2p different client service instances I have the above repeated across a larger aggregate (of M different mp2p client instances) but now with new traffic correlation considerations between different mp2p service instances.
 
And I have not even got on to considering a set of N QoS classes per mp2p 'transport entity', or what this means for entry/exit states for unavailability and prot-sw/restoration of such....not forgetting the need to have 8  levels of nested TCM that need configuring/updating across failure/restoration events too.  Sounds really simple and practical (not!)
 
Are you are seriously telling us this is how operators should design their future transport networks?  I suppose you must be, so can you please point me at the Huawei equipment and network design rules that explain how all this works....I assume they must exist as you keep telling us about deployed networks of this stuff.
 
regards, Neil

	From: Maarten Vissers [mailto:[email-masked]] 
	Sent: 19 August 2009 08:10
	To: Harrison,N,Neil,DEY2 R; [email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] a question about transport path layer and transportService Layer

	Neil,

	You are missing one very important additional means to support this requirement also for clients that want to be supported by a rmp or mp2mp server transport entity, i.e. with multiple sources... i.e. the rmp or mp2mp server transport entity supporting client X and the one supporting client Y contain a number of p2p link connections, which are interconnected by rmp or mp2mp matrix transport entities. Each of those server link connections is traffic engineered and has an enforced CIR/EIR. With this traffic-engineered rmp/mp2mp transport entity architecture you have guaranteed that the traffic behaviour of client X does not impact the SLA/performance experienced by client Y. This architecture is the basis for an open wholesale model for braodband backhaul that is build on the use of E-Tree (rmp) services.
	 
	This traffic engineered rmp/mp2mp transport entity architecture is the reason why I require that the transport entities in the tunnel/path layer must be p2p connections. But the transport entities in the servcie/channel layer can be p2p, p2mp, rmp, mp2mp traffic engineered transport entities supporting clients that demand either a Line (p2p), Tree (p2mp, rmp) or LAN (mp2mp) service.
	 
	Regards,
	Maarten

	Thanks Liu,

	 

	 
	 
	regards, Neil

		Neil 

		best regards 
		liu 

<[email-masked]> 

2009-08-18 18:28 

收件人
<[email-masked]> 
抄送

		  

		  
		  
		Does that help? 
		  
		regards, Neil 

		Neil 

		
		best regards 
		liu 

		
<[email-masked]> 

2009-08-18 15:48 

收件人

		

		 
		Why is this important? 

		 

		 

		 

		 
		regards, Neil 

		ben, 

		best regards 
		liu 

		

2009-08-18 06:54 

收件人

		

		Liu,

		
		
		Ben

---

From: George Newsome <[email-masked]>
Date: Wed, 19 Aug 2009 09:40:38 -0400

Maarten,

> supporting clients that demand either a Line (p2p), Tree (p2mp, rmp) or LAN
Neil is using the term "not impact" absolutely, while you are using it
more loosely.

The physics of the CS mode does not allow for any coupling between demands.

PS modes allow for a whole slew of policies to limit coupling, and many
of those limitations are clearly fit for many purposes. If a PS mode
server is used, then the coupling between server demands is inherited by
the client. This means that the client behaviour is affected by the
server policies, though that fact does not mean that this situation is
always intolerable.

Arguing that there is no coupling because the coupling is tolerable is
not a correct argument.

George

> ------------------------------------------------------------------------
>

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 20 Aug 2009 13:52:00 +0200

George,

more loosely.

Neil indeed seems to like extremes and ignores the intermediate grades, so
you could be right. For me the question is if it fits... If so I consider it
as not having an impact.

> The physics of the CS mode does not allow for any coupling between
demands.

Yes, this is a great feature some years ago, now it seems to be too
restrictive (not flexible enough)... but this may change again in future...
ODUflex gives us flexibility combined with absolute decoupling...

> PS modes allow for a whole slew of policies to limit coupling, and many of
those
> limitations are clearly fit for many purposes. 

This is what is important to me; if it is good enough for the application...
then let's use it an stop complaining that it is not 100%.

> If a PS mode server is used, then the coupling between server demands is
> inherited by the client. This means that the client behaviour is affected
> by the server policies, though that fact does not mean that this situation
> is always intolerable.

Absolutely agree with you. To make life simple again, consider that the PS
server has no policies other then being a fast track for multiple client
instances. What I mean is that the PS tunnel/path transport
entities/connections have unspecified bandwidth; those tunnels are simple
administrations of fat pipes through a (metro or core) domain. In a packet
transport network this is all you need of tunnels. Any bandwdith
administration is done on a per physical resource and per service/channel
transport entity instance. The tunnel provides just a pointer to a set of
physical resources. So when you get a service request you do the path
computation and thus select a number of tunnels to pass through. The
identifiers of the tunnels give you the set of physcial resources being
traversed by the service instance and the CIR/EIR of the service isntance
can now be registered on those physical resources.

What you need to do is to add a so called "resource layer" in parallel to
the layer networks and then register the resource demand per service
instance on the resources in this "resource layer".

> Arguing that there is no coupling because the coupling is tolerable is not
a correct argument.

If I had understood that Neil's "no impact" would have been meant in the
absolute sense, then I would have argued differently.

Thanks,
Maarten

-----Original Message-----
From: George Newsome [mailto:[email-masked]] 
Sent: woensdag 19 augustus 2009 15:41
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] a question about transport path layer and
transportService Layer

Maarten,

Maarten Vissers wrote:
> requirement also for clients that want to be supported by a rmp or 
> mp2mp server transport entity, i.e. with multiple sources... i.e. the 
> rmp or mp2mp server transport entity supporting client X and the one 
> supporting client Y contain a number of p2p link connections, which 
> are interconnected by rmp or mp2mp matrix transport entities. Each of 
> those server link connections is traffic engineered and has an 
> enforced CIR/EIR. With this traffic-engineered rmp/mp2mp transport 
> entity architecture you have guaranteed that the traffic behaviour of 
> client X does not impact the SLA/performance experienced by client Y. 
> This architecture is the basis for an open wholesale model for braodband
backhaul that is build on the use of E-Tree (rmp) services.
> reason why I require that the transport entities in the tunnel/path 
> layer must be p2p connections. But the transport entities in the 
> servcie/channel layer can be p2p, p2mp, rmp, mp2mp traffic engineered 
> transport entities supporting clients that demand either a Line (p2p), 
> Tree (p2mp, rmp) or LAN
> (mp2mp) service.
>
Neil is using the term "not impact" absolutely, while you are using it more
loosely.

PS modes allow for a whole slew of policies to limit coupling, and many of
those limitations are clearly fit for many purposes. If a PS mode server is
used, then the coupling between server demands is inherited by the client.
This means that the client behaviour is affected by the server policies,
though that fact does not mean that this situation is always intolerable.

Arguing that there is no coupling because the coupling is tolerable is not a
correct argument.

George

>     o do not overbook server layer resource ....and this applies to 
> every lower layer network down to the duct.
>  
> MPLS-TP is emulate the co-cs mode because the above are a key 
> requirement of a transport network IMO.
>  
> below), but the server layers under these need to obey the rules I 
> noted above, else there is no resource determinism for the clients.  
> As more and more major customers require service compliance with ITIL 
> principles then IMO it will become increasingly important for 
> operators to be able to prove determinism of service (which implies
determinism of resource).
> -    the real top-of-stack network directly above these constructs is
cl-ps
> in mode, ie one can see an absolute SA, else we have no means to 
recognise
> have noted many times now, a real top-of-stack layer network that 
> supports external message/file/stream applications MUST be present 
> thanks a lot for your explaining in details. I have completely 
> understood what you meaned. but if transport entities only provide P2P 
> and P2MP transport path. how about carrying MP2P or MP2MP services in 
> transport layer network?  whether these MP2P or MP2MP services will be 
> divided into n duplications,then they will be transported by n p2p or p2mp
transport paths?
> Of course, to transfer information across real geographic distance we 
> have to modulate an EM wave...ergo why proper 'transport networks' 
> require a physical bottom-of-stack manifestation.
>   
> considered.  Further, because we don't have parent transport 
> constructs (like connections - which have a precise meaning, but just 
> park that for
units.
> So cl-ps mode traffic units MUST contain the following labels: an 
> defines
> resource-allocation are coupled actions, and this is what makes the 
> link-only-unique forwarding label.  Further, because we cannot violate 
> the single source rule of a parent connection (vital to have 
traffic units IFF the parent connection will
> deterministic resource management.  No choice here in fact, this is 
> the way the physics works in the co-cs mode.  It also means there 
> cannot be any load-sensitive performance impairment inheritance issues 
> (as discussed in my previous mail).  But note the short-cuts on child 
> traffic unit labelling that can be sensibly applied because the parent 
> transport constructs MUST obey the single source rules of a connection in
the co-cs mode.
>   
> The co-ps mode decouples (forwarding) labelling and resource 
> assignment, and it is manifested as irregular time-slices of resource.  
> Here the forwarding label must be explicitly assigned to the child 
> traffic units.  We can still omit the source label in the child 
> traffic units IFF we do not violate the rule of a parent connection, 
> ie single source only.  If you do violate this single source rule (eg 
> MPLS  LDP LSPs or PHP) you have to recover the lost source information 
> some other way.....either as a cl-ps mode client (since as I noted 
> above these traffic units MUST contain an absolute SA label) or as a 
> higher p2p 1-hop degenerate client connection with a label that is 
> unique to the source...which is precisely what a PW label is in 
> MPLS....and this is only technically required because LDP parent mp2p
transport constructs are possible in the co-ps mode.
> p2mp connections constructs can have deterministic resource 
> management, we cannot use these as a recursive atomic building block 
> of topology.  And clearly we cannot use mp2p or mp2mp constructs as 
> recursive topology building blocks, just like we cannot have 
> deterministic resource management of such.  What this means 
> practically is that if p2mp connection constructs (or even mp2p or 
> mp2mp non-connection constructs) are used they can only appear 
> directly in support of the top-of-stack network that directly supports
external message/file/applications....as this top-of-stack layer network
MUST always
> I am very thankful to your explaining in detail. I completely agree 
> your opinions and advice. but here why I need to provide the problem ? 
> IMO, because there is a few difference between " transport path layer "
and "
> service transport layer" . for the former ,it only provides P2P and 
> P2MP transport path. whhile for the later, it needs to carry p2p, p2mp 
> and mp2mp customer services, it is the key problem for service 
> transport layer whether to only P2P and P2MP transport path like 
> transport path layer. or it maybe provide p2p,p2mp and mp2p transport 
> path?
> 
> Once upon a time we had 'unwritten rules' (still are unwritten) for 
> the client/server relationships that made practical sense, ie co-cs 
> mode networks sat at the bottom of the stack (so-called L1 networks), 
> co-ps mode networks sat above these (so-called L2 networks) and cl-ps 
> networks sat above these (so-called L3 networks).  The L1/2/3 
> classification (that originated in the OSI RM) is quite meaningless, 
> ie all networks are always L3, irrespective of their mode.....indeed 
> network mode classification is the only useful classification of network
types.
> nodes and layer N links (between layer N nodes).  The layer N links 
> are end-end connections in a lower layer N-1 network.  The layer N-1 
> layer network is itself composed of layer N-1 nodes and layer N-1 
> end-end connections.  This is a recursive arrangement.  And there are 
> no formal rules for how many layer networks can be recursively nested 
> in such a client/server relationship (these are the 'unwritten rules' I
noted earlier).
> -    there must always be a top-of-stack layer network present.  This
layer
> serves no purpose at all...please keep that point in mind at all 
> times, it is very important as some folks tend to forget this.  The 
> PSTN (a 64k co-cs mode layer network), the Internet (a cl-ps mode 
> layer network) and the ATM B-ISDN (a co-ps mode layer network) are the 
> only layer networks that have been specified to take on this full 
> message/file/stream external application supporting role.  It is also 
> no coincidence that these layer networks have well specified E-NNIs 
> between operating parties since we need this to support a public service
role.
> layer network maps (via lexicon encoding) the binary-based symbols of 
> a higher path layer network into the q'ary-based symbols of a physical 
> section layer network where the key function is the modulation of an 
> EM wave on either metallic, optical or radio media.  This layer 
> network is obviously necessary in order that we can send information
across geographic distance.
> sublayers of LSP) over Ethernet over OTN......or indeed any other 
> almost limitless combination you can think of (these are the 
> 'unwritten rules' again).  However, it should be intuitively obvious 
> that the more filler layer networks there are the greater the 
> design/operational configuration complexity (and thus cost) of the 
> total networking scenario.  In other words we should be striving to 
> introduced in the layer N nodes (which can be a function of traffic 
> load if layer N is either cl-ps or co-ps, this is not true if layer N 
> is co-cs) plus
> (ii) impairments introduced in the layer N links which, by definition, 
> are inherited from the end-end connections in the layer N-1 layer network.
> considerations, ie inherent impairments from the layer N-1 nodes (ie 
> due to their traffic load) and inherited impairments on the layer N-1 
> links for end-end layer N-2 connections
> The reason the above is important is because if I want to design a 
> layer N network I really don't want any uncertainty in the inherited 
> may not own, but simply lease from some other operating party).  
> Ideally I want to be able to design my layer N network to have 
> performance behaviour (for the SLAs I have with my customers) that is 
> under my control as a function of the network traffic load at layer N.  
> However, what I have just stated is only possible if all the lower layer
networks:
> never true for cl-ps mode networks.  And it might be true for co-ps 
> mode networks providing they respect the rules of a connection and do 
> not have overbooked resources.....which is of course why we are only 
> allowing proper p2p and p2mp LSP connections in MPLS-TP and cannot 
> have the mp2p LSP constructs that LDP MPLS creates.
>  
> other naming
> convention) is meaningless at best...just like the L1/2/3 
> network........and its not just 'how many' that impact complexity/cost 
> but also what server mode types exist, since these impact performance
> layer and only provides point-to-point or point-to-multipoints transports
path.
> when pw layer carry customer traffic ,eg. etherent. it will be 
> regarded as part of transport service path. and the customer traffic 
> may be p2p, p2mp and mp2mp services.
> 
> It depends on the context in which the PW is used. I will illustrate 
> by way of two examples:
> 
layer.
> part of a VPLS) then the Ethernet PW is part of the transport service
layer.
wrote:
>> concepts
>> understand them. there are the following red line description about 
>> the
> two
>> to transport path layer or transport service layer? maybe it is 
>> belong to
> either
>> communication is confidential. Recipients named above are obligated 
>> to maintain secrecy and
> are
addressed.
> If
>> you have received this email in error please notify the originator of 
communication to others.
> intended solely for the use of the individual or entity to whom they are
addressed.
> If you have received this email in error please notify the originator 
> of the message. Any views expressed in this message are those of the 
> individual sender.
system.
communication to others.
> intended solely for the use of the individual or entity to whom they are
addressed.
> If you have received this email in error please notify the originator 
> of the message. Any views expressed in this message are those of the 
> individual sender.
system.
communication to others.
> intended solely for the use of the individual or entity to whom they are
addressed.
> If you have received this email in error please notify the originator 
> of the message. Any views expressed in this message are those of the 
> individual sender.
> 
system.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Aug 2009 13:17:40 +0100

The topic in this thread is very important and I don't want to stand in the 
way of you discussing it further.

I think you have strayed into a detailed discussion of network 
architectures. Maybe a better place for this discussion is a list dedicated 
to that topic. For example, the Q12/15 list. Indeed, part of the discussion 
(on MP2P transport) has been moved there.

It would be helpful if we restricted the discussions on this list to details 
of MPLS-TP.

Many thanks,
Adrian

----- Original Message ----- 
From: "Maarten Vissers" <[email-masked]>
To: "'George Newsome'" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, August 20, 2009 12:52 PM
Subject: Re: [mpls-tp] a question about transport path layer and 
transportService Layer

>> by the server policies, though that fact does not mean that this
>> situation is always intolerable.
>
> more
> a