Subject: Re: [mpls-tp] Layer networks and sublayers in MPLS-TP

From: Maarten Vissers <[email-masked]>
Date: Fri, 23 Jan 2009 13:09:12 +0100

Liu,
 
> how to  judge the pw label value x is an MPLS-TP channel/pw layer
connection or ETH channel connection?
 
All MPLS-TP channel/PW and ETH channel/VPLS instances are set up under
control of either network management or a control plane. NMS/CP will select
the label value X and configure in the equipment if this value X represents
a MPLS-TP channel/PW or an ETH channel/VPLS instance.
 
In theory it is possible to allocate a subset of the label values to MPLS-TP
channel/PW connections and an other subset to ETH channel/VPLS instances; e.
g. all odd label values represent MPLS-TP channel/PW  and all even label
values represent ETH channel/VPLS instances. 
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 23 januari 2009 4:49
To: Maarten Vissers
Cc: [email-masked]
Subject: 答复: Re: [mpls-tp] Layer networks and sublayers in MPLS-TP

see red line ,thank you ! 

Maarten Vissers <[email-masked]> 
发件人:  [email-masked] 

2009-01-23 04:37 

收件人
'Ben Niven-Jenkins' <[email-masked]>, [email-masked] 

抄送

主题
Re: [mpls-tp] Layer networks and sublayers in MPLS-TP

Ben,

> The other deviation is is the Ethernet Channel layer network in Maarten's
slides.
> The scope of MPLS-TP is strictly P2P and P2MP LSP and PWs.  MP2MP and RMP
> services can be supported over it but it does not itself provides MP2MP or
RMP constructs. 

The MPLS-TP Path/LSP layer network has as client layer network the ETH
channel layer network. It is important to describe in the MPLS-TP framework
that the ETH channel layer network is a client of the MPLS-TP Path/LSP layer
network. There is no MPLS-TP channel/PW layer network between the ETH
Channel layer network and the MPLS-TP Path/LSP layer network. 

The channel layer terminating and switching MPLS-TP equipment (T-PE and
S-PE) will support both the MPLS-TP channel/PW layer network and ETH channel
layer network. Ethernet UNI-N, I-NNI and E-NNI ports on such T-PE/S-PE nodes
support ETH MEP and ETH MIP functions in parallel to MPLS-TP channel/PW MEP
and MIP functions.

Devices on those interface ports will support both ETH **and** PW MEP/MIP
functions. If a packet with PW label value X may have to be processed by an
ETH MEP/MIP or a PW MEP/MIP function. If PW label value X identifies an
MPLS-TP channel/PW layer connection, then the packets with label value X
will be processed by a PW MEP/MIP function. If the PW label value X
idnetifies an ETH channel layer transport entity (i.e. a VPLS instance),
then the packet will be processed by an ETH MEP/MIP function. 
how to  judge the pw label value x is an MPLS-TP channel/pw layer connection
or ETH channel connection?

This implies that there is an MPLS-TP Path/LSP to MPLS-TP channel/PW and ETH
channel adaptation function (LSP/PW+ETH_A) function in the MPLS-TP Path/LSP
layer network boundary.

The MPLS-TP framework should recognise this adaptation function.

>From an equipment perspective, it is important to minimize the equipment
complexity. Such is only possible if there is full recognition of the
functionality present in such equipment. For the MPLS-TP equipment this
implies that minimizing equipment complexity can only be obtained when we
understand that PW MEP/MIP functions are paired with ETH MEP/MIP functions.
And thus PW OAM is paired with ETH OAM. For the case a device has to support
e.g. 100  MEP/MIP functions, such device would have to support 100 ETH
MEP/MIP functions and 100 PW MEP/MIP functions. 
- When the PW OAM is very different from the ETH OAM, there would be 100
sets of ETH OAM functions needed in the device plus 100 sets of PW OAM
functions.
- When PW OAM has strong commonality with ETH OAM, then it is possible that
the device supports just 100 sets of common ETH/PW OAM functions (only the
OAM headers differ a bit). A great complexity reduction compared to the
first case.

Then there is the one more item to address. It would be possible to carry
MPLS-TP channel/PW layer signals and ETH channel layer signals directly over
a MPLS-TP Section layer trail, without intermediate MPLS-TP Path/LSP layer
trail. Such would be typically found in access links, between e.g. NTU
devices and Metro Edge devices. Refer to figure 2 in
http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/mplstp-equipment-typ
es-and-characteristics-00.doc where you find this case illustrated.

It should be made clear in the framework if this carriage of Channel signals
over Section trail is supported in those access links. If supported, then
the MPLS-TP Section layer network will also have the MPLS-TP channel/PW and
ETH channel layers as client layers and will have an MPLS-TP Section to
MPLS-TP channel/PW and ETH channel adaptation function (LSP/PW+ETH_A).

There are two alternatives:
1) require that a MPLS-TP Path/LSP trail is included; i.e. a few MPLS-TP
channel/PW signals and ETH channel signals are then carried in a single
path/lsp trail and this single path/lsp signal is carried in the section/LSP
trail.
2) require that a MPLS-TP Path/LSP trail is used instead of a Section/LSP
trail.

>From an equipment interworking perspective it is important to explicitly
specify the signal format on such access I-NNI.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ben Niven-Jenkins
Sent: donderdag 22 januari 2009 15:33
To: Malcolm Betts; [email-masked]
Subject: Re: [mpls-tp] Layer networks and sublayers in MPLS-TP

Malcolm, Maarten

I agree.  MPLS-TP as specified consist of two layer networks. An "LSP layer
network" (what Maarten's slides refer to as a Path layer network) and a "PW
layer network" (what Maarten's slides refer to as a Channel layer network).

The other deviation is is the Ethernet Channel layer network in Maarten's
slides.  The scope of MPLS-TP is strictly P2P and P2MP LSP and PWs.  MP2MP
and RMP services can be supported over it but it does not itself provides
MP2MP or RMP constructs.  Discussion of MP2MP or RMP Ethernet support over
an MPLS-TP server in IETF comes under the responsibility of the L2VPN WG
IMO.

Ben

On 22/01/2009 14:18, "Malcolm Betts" <[email-masked]> wrote:

> Maarten, as you are aware this issue was discussed in detail in Q12/15 
> during the development G.8110 the MPLS architecture.  We agreed that 
> MPLS should be modelled using sub layer not new layer networks for 
> each label push/pop.
> 
> Further people have indicated, on this list, strong support for use of 
> the sub layer model for MPLS.
> 
> It appears that you are attempting to modify the ITU model via 
> discussion on an IETF email list.  If you wish to change G.8110 please 
> send a contribution to the ITU.
> 
> Malcolm Betts
> Nortel Networks
> Phone: +1 613 763 7860 (ESN 393)
> email: [email-masked]
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Maarten Vissers
> Sent: Wednesday, January 21, 2009 10:54 AM
> To: [email-masked]
> Subject: [mpls-tp] Layer networks and sublayers in MPLS-TP
> 
> I have created a couple of slides to resolve the ambiguity in MPLS-TP 
> with respect to layer networks and sublayers. You can download those 
> slides from 
> http://ifa.itu.int/t/2009/sg15/exchange/wp3/q12/mpls-tp/layers-and-sub
> la
> yers
> -00.ppt.
> 
> In the first few slides I have copied the relevant text in G.805
> (03/2000) for layer networks, sublayers and the transport functional 
> group. I have applied these specifications to several transport 
> network technologies to illustrate the principles defined. I then have 
> applied these specifications to the MPLS-TP case.
> 
> I have also illustrated the carrier-carrier application in a generic 
> manner and for several transport network technologies. I have then 
> applied this carrier-carrier application to the MPLS-TP case.
> 
> My conclusion is that G.805 gives clear guidance for the use of the 
> terms "layer network" and "sublayer". On the basis of G.805, MPLS-TP 
> will contain multiple "MPLS-TP layer network" instances, and each 
> MPLS-TP layer network instance may have one or more "connection 
> related SubLayers".
> 
> I propose that we add the presented MPLS-TP layer stack with its layer 
> networks, sublayers and carrier-carrier applications to the MPLS-TP 
> framework.
> 
> Regards,
> Maarten
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

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

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

--------------------------------------------------------

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.
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp