Subject: [mpls-tp] Can MPLS-TP support a MPLS-TP section layer service?

From: Maarten Vissers <[email-masked]>
Date: Wed, 07 Apr 2010 09:06:09 +0200

The MPLS-TP framework draft identifies the following service types:
- PW-based services
- MPLS Labelled services (client is MPLS(-TP))
- IP transport.

In a multi-carrier MPLS-TP environment, and MPLS-TP carrier network may be
required to support besides those services also MPLS-TP section layer
services. E.g. to interconnected two subnetworks of carrier A through the
network of carrier B. The MPLS-TP section transport path signal is then
carried in a service LSP through the network of carrier B. To be able to
separate the section layer OAM from the service LSP OAM, it is necessary to
add a section (LSP) label stack entry header to the section layer signal
before inserting service LSP OAM.

The section transport path signal is an unlabelled (LSP) signal and is as
such not supported in today's draft as a possible service. Is it the
intention to prevent that MPLS-TP networks support a MPLS-TP section
service, or is it an omission and should MPLS-TP also support 'MPLS
Unlabelled services'?

Regards,
Maarten

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 07 Apr 2010 10:11:13 +0100

Martin

What do you mean by an MPLS unlabeled service?

Do you mean an abstract packet type (presumably type unknown to the 
MPLS-TP n/w)?

- Stewart

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

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 07 Apr 2010 12:39:59 +0200

Stewart,

The MPLS-TP Section layer transport path signal looks like an unlabellled
'Section-LSP' signal. 
This unlabelled 'Section-LSP' signal contains unlabelled 'Section-LSP' OAM
and 'Section-LSP' clients (e.g. Transport-LSPs, Transport-PST-LSPs,
Service-LSPs, Service-PST-LSPs and/or PWs).

Unlabelled 'Section-LSP' OAM packets starts with a GAL header and then the
remainder of the 'Section-LSP' OAM.
Unlabelled 'Section-LSP' client packets start with the client label stack
entry header (e.g. transport-lsp, service-lsp, pst-lsp or pw label stack
entry header).

When such unlabelled 'Section-LSP' signal is applied as a (port-based)
service to e.g. an MPLS-TP network of another carrier, then the e.g. UNI-N
port would add a label stack entry header to the packets of the unlabelled
'Section-LSP', creating a labelled 'Section-LSP' packet stream after which
this UNI-N port would add the Service-LSP OAM. The resulting signal is then
a Service-LSP signal containing labelled Section-LSP packets and Service-LSP
OAM packets. Both sets of packets will then be equipped with a Service-LSP
label stack entry header.

Regards,
Maarten

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: woensdag 7 april 2010 11:11
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP support a MPLS-TP section layer service?

Martin

Do you mean an abstract packet type (presumably type unknown to the MPLS-TP
n/w)?

- Stewart

Maarten Vissers wrote:
> In a multi-carrier MPLS-TP environment, and MPLS-TP carrier network 
> may be required to support besides those services also MPLS-TP section 
> layer services. E.g. to interconnected two subnetworks of carrier A 
> through the network of carrier B. The MPLS-TP section transport path 
> signal is then carried in a service LSP through the network of carrier 
> B. To be able to separate the section layer OAM from the service LSP 
> OAM, it is necessary to add a section (LSP) label stack entry header 
> to the section layer signal before inserting service LSP OAM.
>
> The section transport path signal is an unlabelled (LSP) signal and is 
> as such not supported in today's draft as a possible service. Is it 
> the intention to prevent that MPLS-TP networks support a MPLS-TP 
> section service, or is it an omission and should MPLS-TP also support 
> 'MPLS Unlabelled services'?
>
> Regards,
> Maarten
>
>  
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 07 Apr 2010 15:23:50 +0100

Maarten

This looks like it is covered by column 2 and column 3 in Fig 2.

Your client labeled packet would be one of these two case.

Is your concern that we did not explain how OAM is carried, or do you 
have in mind to present a packet that is something other than PW, MPLS 
or IP?

- Stewart

---

From: Dan Frost <[email-masked]>
Date: Wed, 7 Apr 2010 15:24:38 +0100

Hi Maarten,

If we have understood your comment correctly, this kind of port-based
"section service" can be provided using the existing PW and network
layer adaptations.  In the PW case, the section is provided as, for
example, an Ethernet or PPP link between the attached client devices.
In the network layer case, the link-layer framing is stripped at the
ingress UNI and added at the egress UNI, and only the network layer
protocol packets (e.g. IP and MPLS(-TP)) are transported.

-d

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 07 Apr 2010 17:23:08 +0200

Stewart,

Column 2 in Figure 2 represents how a MPLS or MPLS-TP LSP client instance
packet carrying a PW is encapsulated into a Service-LSP. This column does
not illustrate how the client LSP OAM or PW OAM is encapsulated, but as this
OAM is located behind the client LSP lbl (S=0) it would be looking like 
1) MPLS-TP Service-LSP lbl (S=0) - client LSP lbl (S=0) - GAL - GACH - OAM
PDU
2) MPLS-TP Service-LSP lbl (S=0) - client LSP lbl (S=0) - PW lbl (S=1) - ACH
- OAM PDU.

Column 3 in Figure 2 represents how a MPLS or MPLS-TP LSP client instance
carrying IP is encapsulated into a Service-LSP. This column does not
illustrate how the client LSP OAM is encapsulated, but as this OAM is
located behind the client LSP lbl (S=1) it would be looking like 
1) MPLS-TP Service-LSP lbl (S=0) - client LSP lbl (S=1) - GAL - GACH - OAM
PDU.

I have been assuming that the client LSP lbl (S=0 or S=1) are present in the
UNI; i.e. are not inserted in the ingress UNI-N and removed in the egress
UNI-N ports. These client LSP lbl values are either preserved or swapped in
the UNI-N ports.

For the case of the section-LSP, the UNI would not carry a section-LSP
label, and the UNI-N ingress port has to add such label stack entry header
with LBL,TC,S,TTL fields to the section-LSP client packets and section-LSP
OAM packets. The UNI-N ingress port will also have to decide which value to
put into the added TC field; e.g. all packets get same TC value, or packets
get different TC values. For the latter case, the section-LSP TC value could
be derived from the TC value in the GAL (case of section OAM) or section's
client label (case of non-OAM) TC value.

My main question is if such section-LSP packet stream (which packets do not
carry a section-LSP label) can be considered to be a service supported by a
MPLS-TP network. If it is to be considered as a valid service, then we have
to make sure that the encapsulation is well specified, which in this case
requires the insertion of an additional label. Perhaps it is possible to
specify the use of an Encap label for this case, nonetheless that the
service LSP is "supporting only a one network layer protocol payload type".
It may help if you include this as an exception to the first note on page 28
of the framework document; i.e. include that the Encapsulation label must
not be omitted when a Section-LSP is the client.

Regards,
Maarten

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: woensdag 7 april 2010 16:24
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP support a MPLS-TP section layer service?

Maarten

Is your concern that we did not explain how OAM is carried, or do you have
in mind to present a packet that is something other than PW, MPLS or IP?

- Stewart

Maarten Vissers wrote:
> Stewart,
>
> The MPLS-TP Section layer transport path signal looks like an 
> unlabellled 'Section-LSP' signal.
> This unlabelled 'Section-LSP' signal contains unlabelled 'Section-LSP' 
> OAM and 'Section-LSP' clients (e.g. Transport-LSPs, 
> Transport-PST-LSPs, Service-LSPs, Service-PST-LSPs and/or PWs).
>
> Unlabelled 'Section-LSP' OAM packets starts with a GAL header and then 
> the remainder of the 'Section-LSP' OAM.
> Unlabelled 'Section-LSP' client packets start with the client label 
> stack entry header (e.g. transport-lsp, service-lsp, pst-lsp or pw 
> label stack entry header).
>
> service to e.g. an MPLS-TP network of another carrier, then the e.g. 
> UNI-N port would add a label stack entry header to the packets of the 
> unlabelled 'Section-LSP', creating a labelled 'Section-LSP' packet 
> stream after which this UNI-N port would add the Service-LSP OAM. The 
> resulting signal is then a Service-LSP signal containing labelled 
> Section-LSP packets and Service-LSP OAM packets. Both sets of packets 
> will then be equipped with a Service-LSP label stack entry header.
>
> Regards,
> Maarten
>
>
>> may be required to support besides those services also MPLS-TP 
>> section layer services. E.g. to interconnected two subnetworks of 
>> carrier A through the network of carrier B. The MPLS-TP section 
>> transport path signal is then carried in a service LSP through the 
>> network of carrier B. To be able to separate the section layer OAM 
>> from the service LSP OAM, it is necessary to add a section (LSP) 
>> label stack entry header to the section layer signal before inserting
service LSP OAM.
>>
>> The section transport path signal is an unlabelled (LSP) signal and 
>> is as such not supported in today's draft as a possible service. Is 
>> it the intention to prevent that MPLS-TP networks support a MPLS-TP

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 08 Apr 2010 02:27:00 -0400

In message <[email-masked]>
> service, or is it an omission and should MPLS-TP also support 'MPLS

Maarten,

You seem to be describing a hierarchical LSP.

In which case it is a "MPLS Labelled service" and carrier A is the
client of carrer B.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 08 Apr 2010 09:14:42 +0200

Hi Dan,

I was looking at the following case:

     Carrier A                                          Carrier A
---------------------                              ---------------------
|      client       |                              |       client      |
---------------------                              ---------------------
| transport service |                              | transport service |
---------------------                              ---------------------
| transport path |  |           Carrier B          | transport path |  |
------------------  |     ---------------------    ------------------  |
|       section     | --- |      client       |--- |    section        |
---------------------     ---------------------    ---------------------
                          | transport service |
                          ---------------------
                          | transport path |  |
                          ------------------  |
                          |      section      |
                          ---------------------

                    MPLS-TP section transport path
             |<-----------o-------------------o-------->|
        Section-MEP     (MIP)               (MIP)   Section-MEP
                            transport service
                              transport path
                           |<---o---o---o--->|
                  svc-LSP-MEP  MIP MIP MIP  svc-LSP-MEP 

Carrier A would like to set up a MPLS-TP Section layer transport path
between two of its e.g. PE nodes, which are interconnected via the network
of Carrier B. An example could be that the right Carrier A PE node is a
customer located equipment (CLE), which can be reached via a regional
carrier network (see e.g. Rec. G.8601).

By making the above figure and adding the MEP and MIP locations, I notice
that for the case there is no need for Section MIP functions in the edge
ports of carrier B, it is possible to deploy a unlabelled (or label-less)
section-LSP. But as soon as a section MIP function is required, then the
section-LSP will have to be labelled as TTL field is needed to support
loopback (TTL expiry is needed)... consequence of this latter would be that
the section-LSP service becomes a LSP service for a port-based labelled LSP.

Regards,
Maarten

-----Original Message-----
From: Dan Frost [mailto:[email-masked]] 
Sent: woensdag 7 april 2010 16:25
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP support a MPLS-TP section layer service?

Hi Maarten,

If we have understood your comment correctly, this kind of port-based
"section service" can be provided using the existing PW and network layer
adaptations.  In the PW case, the section is provided as, for example, an
Ethernet or PPP link between the attached client devices.
In the network layer case, the link-layer framing is stripped at the ingress
UNI and added at the egress UNI, and only the network layer protocol packets
(e.g. IP and MPLS(-TP)) are transported.

-d

service LSP OAM.
> > section service, or is it an omission and should MPLS-TP also 
> > support 'MPLS Unlabelled services'?
> >
> > Regards,
> > Maarten
> >
> >  
> >

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 08 Apr 2010 09:41:56 +0200

Curtis,

I agree with you that it is a hierarchical LSP case. 

>From the service perspective it looks like a "MPLS Label-less service" 
as the section-LSP is specified to be without a label stack entry header.

My understanding at this point is that this MPLS-TP port-based service type
is supported in MPLS-TP. 
Remaining item is if the draft should include some dedicated text to
describe the processing on the UNI-N port for this specific case.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 8 april 2010 8:27
To: Maarten Vissers
Cc: [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP support a MPLS-TP section layer service?

Maarten,

In which case it is a "MPLS Labelled service" and carrier A is the client of
carrer B.

Curtis

---

From: [email-masked]
Date: Thu, 8 Apr 2010 11:21:11 -0400

Maarten,

I must be missing something.  I thought that a section provided a direct 
adjacency (i.e. no label swapping) between a pair of nodes, in which case 
how can a MIP exist between these nodes.  Perhaps you could explain by 
adding the label stacks to your example below.

Regards,

Malcolm

Maarten Vissers <[email-masked]> 
Sent by: [email-masked]
08/04/2010 03:14 AM

To
'Dan Frost' <[email-masked]>
cc
[email-masked]
Subject
Re: [mpls-tp] Can MPLS-TP support a MPLS-TP section layer service?

Hi Dan,

     Carrier A                                          Carrier A

By making the above figure and adding the MEP and MIP locations, I notice
that for the case there is no need for Section MIP functions in the edge
ports of carrier B, it is possible to deploy a unlabelled (or label-less)
section-LSP. But as soon as a section MIP function is required, then the
section-LSP will have to be labelled as TTL field is needed to support
loopback (TTL expiry is needed)... consequence of this latter would be 
that
the section-LSP service becomes a LSP service for a port-based labelled 
LSP.

Regards,
Maarten

-----Original Message-----
From: Dan Frost [mailto:[email-masked]] 
Sent: woensdag 7 april 2010 16:25
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP support a MPLS-TP section layer 
service?

Hi Maarten,

ingress
UNI and added at the egress UNI, and only the network layer protocol 
packets

-d

service LSP OAM.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 08 Apr 2010 23:29:47 -0400

In message <[email-masked]>

Maarten,

I did not find the Section support to be at all confusing.  A Section
in layer N is a Path Segment Tunnel in layer N-1.  Add a label, get to
the other side and pop the label.  That is label hierarchy though the
PSC-1 to PSC-4 signaling does not need to come into play since any
control place signaling is at different layers.

Reread "3.2.  Sections" in draft-ietf-mpls-tp-data-plane-01 and look
at "3.13.  Path Segment Tunnels" in draft-ietf-mpls-tp-framework-11
and it should make sense.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 09 Apr 2010 09:18:57 +0200

Malcolm,

Consider that the Section layer transport path is a "trail" in the Section
layer network. Such Section trail is defined to connect two Section layer
Access Points. The Section trail consists of two Section_TT functions
interconnected by a Section "network connection". The Section network
connection may be including a single Section "link connection", or multiple
"link connections" and "matrix connections".

For a Section layer the most common appearance of a network connection is a
single link connection (in which case there are no MIPs). But with the
MPLS-TP technology the Section network connections may also appear as a set
of link connections and matrix connections when the section trail is carried
as a service through another network (e.g. OTN or other MPLS-TP network) (in
which case there are MIPs at the edge of the other network).

The section-LSP connects in both cases two adjacent Carrier A nodes.

The MPLS-TP label stacks in this example may be as depicted in the following
figures: 

             # no section-LSP (A) label #
--------------------------------------------------------
|              transport-LSP lbl              | | GAL  |
----------------------------------------------- --------
|     PW lbl     | |   svc-LSP lbl   | | GAL  | | GAch |
------------------ ------------------- -------- --------
| client | | ACH | | Encap  | | GAL  | | GAch | | OAM  |
|  data  | ------- ---------- -------- -------- --------
---------- | OAM | | Client | | GAch | | OAM  |
           ------- |  data  | -------- -------- Section
                   | or OAM | | OAM  |            OAM
           Service ---------- --------  Transpt   (A)
             OAM                          OAM
             (A)              Service     (A)
                                OAM
                                (A)
Figure 1 - label stack on interfaces between Carrier A and B networks

                          # no section-LSP (B) label #
----------------------------------------------------------------------------
-------
|                              transport-LSP lbl (B)                     | |
GAL  |
--------------------------------------------------------------------------
--------
|                         svc-LSP lbl (B)                       | | GAL  | |
GAch |
----------------------------------------------------------------- --------
--------
|            **Encap or section-LSP lbl** (A)          | | GAL  | | GAch | |
OAM  |
-------------------------------------------------------- -------- --------
--------
|              transport-LSP lbl (A)          | | GAL  | | GAch | | OAM  |
----------------------------------------------- -------- -------- --------
Section
|     PW lbl     | | svc-LSP lbl (A) | | GAL  | | GAch | | OAM  |
OAM
------------------ ------------------- -------- -------- -------- Transpt
(B)
| client | | ACH | | Encap  | | GAL  | | GAch | | OAM  |            OAM
|  data  | ------- ---------- -------- -------- -------- Service    (B)
---------- | OAM | | Client | | GAch | | OAM  |            OAM
           ------- |  data  | -------- -------- Section    (B)
                   | or OAM | | OAM  |            OAM
           Service ---------- --------  Transpt   (A)
             OAM                          OAM
             (A)              Service     (A)
                                OAM
                                (A)

Figure 2 - label stack on interface within Carrier B network

It would be possible to label the Section-LSP of Carrier A, and this might
be necessary to address Section MIP functions at the edges of Carrier B
network. Figures 3/4 show the label stacks for this case.

--------------------------------------------------------
|                  section-LSP lbl                     |
--------------------------------------------------------
|              transport-LSP lbl              | | GAL  |
----------------------------------------------- --------
|     PW lbl     | |   svc-LSP lbl   | | GAL  | | GAch |
------------------ ------------------- -------- --------
| client | | ACH | | Encap  | | GAL  | | GAch | | OAM  |
|  data  | ------- ---------- -------- -------- --------
---------- | OAM | | Client | | GAch | | OAM  |
           ------- |  data  | -------- -------- Section
                   | or OAM | | OAM  |            OAM
           Service ---------- --------  Transpt   (A)
             OAM                          OAM
             (A)              Service     (A)
                                OAM
                                (A)
Figure 3 - label stack on interfaces between Carrier A and B networks when
Carrier A section-LSP is labelled

                          # no section-LSP (B) label #
----------------------------------------------------------------------------
-------
|                              transport-LSP lbl (B)                     | |
GAL  |
--------------------------------------------------------------------------
--------
|                         svc-LSP lbl (B)                       | | GAL  | |
GAch |
----------------------------------------------------------------- --------
--------
|                    section-LSP lbl (A)               | | GAL  | | GAch | |
OAM  |
-------------------------------------------------------- -------- --------
--------
|              transport-LSP lbl (A)          | | GAL  | | GAch | | OAM  |
----------------------------------------------- -------- -------- --------
Section
|     PW lbl     | | svc-LSP lbl (a) | | GAL  | | GAch | | OAM  |
OAM
------------------ ------------------- -------- -------- -------- Transpt
(B)
| client | | ACH | | Encap  | | GAL  | | GAch | | OAM  |            OAM
|  data  | ------- ---------- -------- -------- -------- Service    (B)
---------- | OAM | | Client | | GAch | | OAM  |            OAM
           ------- |  data  | -------- -------- Section    (B)
                   | or OAM | | OAM  |            OAM
           Service ---------- --------  Transpt   (A)
             OAM                          OAM
             (A)              Service     (A)
                                OAM
                                (A)

Figure 4 - label stack on interface within Carrier B network when Carrier A
section-LSP is labelled

If carriers A and B would like to monitor the status/performance of the
links between their networks it is possible to activate Section-PST-LSPs on
those links. Section-PST-LSPs terminate in carrier A and B edge nodes.
Figure 3 would then be extended with OAM for this additional Section-PST MEG
level (see Figure 5). Now the section-PST-LSP does not have to have a label.

                # no section-PST-LSP (A-B) label #
-----------------------------------------------------------------
|                    section-LSP lbl                   | | GAL  |
-------------------------------------------------------- --------
|              transport-LSP lbl              | | GAL  | | GAch |
----------------------------------------------- -------- --------
|     PW lbl     | |   svc-LSP lbl   | | GAL  | | GAch | | OAM  |
------------------ ------------------- -------- -------- --------
| client | | ACH | | Encap  | | GAL  | | GAch | | OAM  |
|  data  | ------- ---------- -------- -------- -------- Section
---------- | OAM | | Client | | GAch | | OAM  |          PST OAM
           ------- |  data  | -------- -------- Section   (A-B)
                   | or OAM | | OAM  |            OAM
           Service ---------- --------  Transpt   (A)
             OAM                          OAM
             (A)              Service     (A)
                                OAM
                                (A)

Figure 5 - label stack on interfaces between Carrier A and B networks when
Carrier A section-LSP is labelled and supports label-less Section-PST-LSP
OAM

Regards,
Maarten

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 8 april 2010 17:21
To: Maarten Vissers
Cc: 'Dan Frost'; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP support a MPLS-TP section layer service?

Maarten, 

Regards, 

Malcolm 

08/04/2010 03:14 AM 

To

Hi Dan,

    Carrier A                                          Carrier A

Regards,
Maarten

-----Original Message-----
From: Dan Frost [mailto:[email-masked]] 
Sent: woensdag 7 april 2010 16:25
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Can MPLS-TP support a MPLS-TP section layer service?

Hi Maarten,

-d

service?
service LSP OAM.