Subject: Re: [mpls-tp] MPLS over OTN

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 1 Aug 2008 09:53:24 +0100

Hi Howard,

[adding MPLS-TP mailing list]

Accurate representation of our conversation.
That is, in GMPLS we have label type, switching type, encoding type, and 
G-PID.
G-PID identifies the payload and re-uses the Ethertype codepoints. Thus we 
can carry MPLS.
If GFP is used for framing, it must also identify the payload and, as you 
point out, GFP has an MPLS codepoint.

That the GFP codepoint for MPLS is the same as that for "T-MPLS" is good for 
Option 1 (which is where we are) since there is no practical difference 
between MPLS and MPLS-TP.

Now, the operation of MPLS over OTN that you describe is actually the 
operation of an OTN. So the issues of control channels in OTN are exactly as 
you describe, but have nothing to do with the payload protocol. This is 
simply GMPLS control of OTN. Period.

GMPLS control of MPLS-TP is a different kettle of ball games. Here the 
switching type is PSC: the same switching type as for MPLS. A feature of 
GMPLS is that there is *logical* separation of control plane and data plane. 
This means that the control plane can be in-band (MPLS-TE), out-of-band but 
in-fibre (SONET/SDH or OSC), or out-of-fibre.

MPLS-TP requirements say that it must be possible to operate the network "in 
the absence of IP." I have taken this to mean "in the absence of IP routing 
and forwarding" (but this is my opinion and there is no explicit evidence in 
the requirements I-D). With this view...
- We can use IP identifiers (addresses) in the data plane and the control 
plane
- We can use IP-based control protocols (GMPLS)
- We can use an IP-based control network if available, but we cannot
   mandate it
- Control entities that need to communicate must be allowed to be
   IP-adjacent so that there is no requirement for IP-forwarding in the
   network

I believe we can do all of the above, and often do in GMPLS networks.
The crunch questions are:
1. What is the physical technology for the data links in the control plane?
2. How do we identify control plane traffic when it arrives at a node?
3. How do we exchange control plane messages between nodes that
   do not have a common data link in the control plane?

Answers are:
1. We don't care :-)
    But a possible answer in MPLS-TP is an LSP (e.g. a reserved label)
2. From the data link (since there is no need to disambiguate the control
   plane traffic from any other traffic on the data link)
3. This is a more tricky question. However nearly all of the messages
   are exchanged only between data-plane-adjacent nodes. This can be
   the case in the IGP-TE protocols, and is true for all messages in
   RSVP-TE with a couple of exceptions (below). It is also the case for
   LMP. So IP forwarding is not required in the control plane.
   The tricky cases are:
   - echo response in LSP Ping (we are rebuilding the OAM)
   - Notify message in RSVP-TE (we are considering OAM approaches
     for the uses of Notify where IP forwarding is not available)
   - "Targeted Path messages" used in hierarchical LSPs (and LSP
      stitching). In these cases we are effectively building a virtual
      data plane adjacency and should build a parallel virtual control
      plane link between the end points (e.g. an LSP).

We should note that the output of the JWT *appears* to be that "GMPLS meets 
the requirements of a control plane for MPLS-TP."

We should also note that management plane operation of MPLS-TP is a 
requirement, and we must assume that management plane messages may need to 
be exchanged between management stations and network nodes using some 
protocol and connectivity.

</homily>

Adrian
----- Original Message ----- 
From: "Howard Green" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 31, 2008 5:55 PM
Subject: MPLS over OTN

Just to record for the list a chat with Adrian and Lou Berger. I
discover from reading G.7041 Amendment 2 that there is a codepoint
defined to allow unicast MPLS frames to be carried over OTN (ODUx)
channels by way of GFP encoding. Reading RFC 4328, there is an encoding
type for ODUx, and the switching type is TDM. There is no specific G-PID
value defined for the MPLS codepoint (which was probably defined
concurrently with the writing of RFC 4328). Adrian and Lou took the view
that in this situation, the use of the unicast MPLS ethertype (#8847)
would define for signalling this bearer type (as described in RFC 3471).

This is relevant partly because G.7041 amendment 2 defines the codepoint
to be for "MPLS or T-MPLS". I assume that this usage carries over to
MPLS-TP. In this situation,interestingly, there is no prospect of inband
IP control, and so GMPLS is the only control plane option.
Is this correct?
Regards Howard

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