Subject: [mpls-tp] draft-beller-mpls-tp-gach-dcn-01.txt

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 13 Mar 2009 17:10:17 -0000

Hi,

Looking at the liaison just received, draft-beller-mpls-tp-gach-dcn-01.txt 
already includes precisely these requirements.

So the authors would like to ask the chairs whether they would consider 
making this a working group draft.

Obviously, as any changes in gal/gach come about, this draft will be updated 
to reflect them.

Thanks,
Adrian
----- Original Message ----- 
From: "Greg Jones (ITU-T SG 15)" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Friday, March 13, 2009 11:14 AM
Subject: New Liaison Statement, "LS33 - Liaison Response re MPLS-TP support 
for MCC and SCC"

> Title: LS33 - Liaison Response re MPLS-TP support for MCC and SCC
> Submission Date: 2009-03-13
> URL of the IETF Web page: 
> https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=513
> Please reply by 2009-05-18

---

From: Martin Vigoureux <[email-masked]>
Date: Mon, 16 Mar 2009 03:12:21 +0100

Adrian,

independently of your request (which I support) please find below
some comments (three general ones and then in-line) to the draft.

- I suggest that the changes brought to tp-gach-gal-01 be
   reflected in tp-gach-dcn (e.g., those relating to clarifications
   wrt ACH & G-ACh)
- You do not explicitly say that ACH TLVs may be present so I guess
   that the ACH TLV Header must not be used. Is that correct?
   Maybe you could add one or two sentences clarifying that point.
- You do not talk about the applicability of that mechanism between
   PEs. Is that on purpose?
   Maybe you could add some text clarifying whether or not
   the mechanism applies.

----------------------------------------------------------------------
Abstract

A Generic Associated Channel (G-ACH) has been defined as an extension
of the pseudowire Associated Channel Header (ACH) to enable the
realization of a control/communication channel associated with
Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs),
MPLS pseudowires (PWs), MPLS LSP segments, and MPLS sections between
adjacent MPLS-capable devices.

mv> ACH hasn't been extended. The applicability of the PW associated
     control channel has been generalized and this channel is now
     referred to as Generic Associated Channel (G-ACh) and the ACH
     (Associated Channel Header) is used in the data plane to materialize
     that control channel.

The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS
architecture that identifies elements of the MPLS toolkit that may be
combined to build a carrier grade packet transport network based on
MPLS packet switching technology.

mv> I suggest to leave the exact definition of MPLS-TP under the
     responsibility of tp-requirements and tp-framework and so to remove
     that paragraph or simply provide a pointer to these documents,
     as it is done, by the way, later in this document.

This document describes how the G-ACH may be used to provide the
infrastructure that forms part of the Management Communication
Network (MCN) and a Signaling Communication Network (SCN).
Collectively, the MCN and SCN may be referred to as the Data
Communication Network (DCN). The document explains how MCN and SCN
packets are encapsulated, carried on the G-ACH, and demultiplexed for
delivery to the management or signaling/routing components on a label
switching router (LSR).

c/how the G-ACH may/how the G-ACh may/
c/carried on the G-ACH/carried on the G-ACh/

It should be noted that the use of the G-ACH to provide connectivity
for the DCN is intended for use only where the MPLS-TP network is not
capable encapsulating or delivering native DCN messages.

c/the use of the G-ACH/the use of the G-ACh/

mv> Do you mean that IP capable LSRs must not use that mechanism?

Conventions used in this document

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in
    RFC-2119 [RFC2119].

1. Introduction

The associated channel header (ACH) is specified in [RFC4385]. It is
a packet header format for use on pseudowire (PW) packets in order to
identify packets used for OAM and similar functions.

The ACH is generalized for use on any Multiprotocol Label Switching
(MPLS) Label Switching Path (LSP) in [GAL-GACH]. The generalized
concept is referred to as the Generic Associated Channel (G-ACH) and
is intended to create a control/communication channel associated with
the LSP that can be used to carry packets used for OAM and similar
functions (e.g. control plane messages).

c/The ACH is generalized for use on any/The use of the ACH is
generalized to apply on any/
c/Generic Associated Channel (G-ACH)/Generic Associated Channel (G-ACh)/

The purpose of a packet carried on the G-ACH is indicated by the
value carried by the PW Associated Channel Type field of the G-ACH
and a registry of values is maintained by IANA.

c/on the G-ACH/on the G-ACh/
c/by the PW Associated Channel Type field of the G-ACH/by the Channel
Type field of the ACH/

mv> should a reference to the registry be provided (i.e., 4446)?

The MPLS transport profile (MPLS-TP) is described in [MPLS-TP].
MPLS-TP is the application of MPLS to construct a packet transport
network. It constitutes a profile of MPLS that enables operational
models typical in transport networks, which includes additional OAM,
survivability and other maintenance functions not previously
supported by MPLS.

Label Switching Routers in MPLS networks may be operated using
management protocols or control plane protocols. Messaging in these
protocols is normally achieved using IP packets exchanged over IP-
capable interfaces. However, some LSRs in MPLS-TP networks may be
constructed without support for direct IP encapsulation on their
line-side interfaces and without access to an out-of-fiber data
communication network. In order that such LSRs can communicate using
management plane or control plane protocols channels must be provided
and the only available mechanism is to use an MPLS label.

mv> Are only LSRs concerned by the solution provided by this document?

The G-ACH provides a suitable mechanism, and this document defines
processes and procedures to allow the G-ACH to be used to build a
management communication network (MCN) and a signaling communication
network (SCN) together known as the data communication network (DCN)
[G.7712].

c/The G-ACH/The G-ACh/
c/the G-ACH/the G-ACh/

1.1. Requirements

    The requirements presented in this section are based on those
    communicated to the IETF by the ITU-T.

    1. A packet encapsulation mechanism must be provided to support the
       transport of MCN and SCN packets over the G-ACh.

    2. The G-ACh carrying the MCN and SCN packets shall support the
       following application scenarios:

       a. The G-ACh interconnects two adjacent MPLS-TP nodes (used when
          the server layer does not provide a Management Communication
          Channel (MCC) or a Signalling Communication Channel (SCC)).

       b. The G-ACh is carried by a MPLS-TP tunnel that traverses another
          operator's domain (carrier's carrier scenario)

    3. The G-ACh shall provide two independent channels: a MCC to build
       the MCN and a SCC to build the SCN. The G-ACh packet header shall
       indicate whether the packet is a MCC or an SCC packet in order to
       forward it to the management or control plane application for
       processing.

    4. The channel separation mechanism shall allow the use of separate
       rate limiters and traffic shaping functions for each channel (MCC
       and SCC) ensuring that the flows do not exceed their assigned
       traffic profile. The rate limiter and traffic shaper are outside
       the scope of the MCC and SCC definition.

    5. The G-ACh that carries the MCC and SCC shall be capable of
       carrying different OSI layer 3 (network layer) PDUs. These shall
       include IPv4, IPv6, and OSI PDUs. The G-ACh header of the MCC/SCC
       packet shall indicate which layer 3 PDU is contained in the
       payload field of the packet such that the packet can be forwarded
       to the related layer 3 process within the management and control
       plane application, respectively, for further processing.

    6. The G-ACh is not required to provide specific security mechanisms.
       However, the management or control plane protocols that operate
       over the MCC or SCC are required to provide adequate security
       mechanisms in order not to be susceptible to security attacks.

2. Procedures

Figure 1 depicts the format of an MCC/SCC packet that is sent over
the G-ACH. To send an MCC/SCC packet on the G-ACH, the MCC/SCC packet
is prepended with the extended G-ACH header. This extended G-ACH
header is composed of the G-ACH header as defined in [GAL-GACH] and
is extended by four bytes providing an 8-bit protocol identifier
(PID) field. The remaining 24 bits of the header extension are
reserved.

c/over the G-ACH/over the G-ACh/
c/on the G-ACH/on the G-ACh/

mv> Choose either "*on* the G-ACh" or "*over* the G-ACh"

mv> I do not quite like the notion of extended header to refer to
the ACH + the 32 bits word defined here. Wouldn't it be better to
call this word the DCN Header?

c/the extended G-ACH header/the DCN Header itself prepended with
the ACH/
c/This extended G-ACH header is composed of the G-ACH header as defined
in [GAL-GACH] and is extended by four bytes providing an 8-bit protocol
identifier (PID) field. The remaining 24 bits of the header extension
are reserved./This DCN Header is long of four bytes providing an 8-bit
protocol identifier (PID) field and the remaining 24 bits of the header
extension are reserved.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version|A|  Reserved   |         Channel Type          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Reserved                   |      PID      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         MCC/SCC Packet                        |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 1: MCC/SCC Packet with Associated Channel Header

mv> The A bit has disappeared in 02 of tp-gach-gal

o The Channel Type field determines whether the message is an MCC or
   an SCC message. See Section 4 for the codepoint assignments.

o The PID field indicates the PDU type of the MCC/SCC message

   The following PID values are defined:

   0x00        IPv4
   0x01        IPv6
   0x02        OSI
   0x03-0xFF   Reserved

Editor Note: This approach may be changed to use the G-ACH Protocol
Identifier TLV if that work is progressed.

mv> what is the Protocol Identifier TLV?

If the PID is OSI, the first octet of the OSI PDU header (Network
Layer Protocol Identifier) as defined in [ISO8473] indicates the
network layer PDU which can be CLNP (0x81), ES-IS (0x82), or IS-IS
(0x83) as specified in [ISO9577].

When the G-ACH sender receives an MCC message from the management
application that is supposed to be sent over the MCC, the sender
creates the extended the G-ACH header depending on the MCC layer 3
PDU, sets the Channel Type field to MCC, and prepends the MCC message
with the extended G-ACH header. The same procedure is applied when a
control plane message is supposed to be sent over the SCC. In this
case, the sender sets the Channel Type field to SCC.

mv> where the MCC/SCC packet comes from before being sent on the G-ACh
     is for me completely outside the scope of this document and so I
     suggest to rework the above paragraph only mentioning the sending
     procedure.

If the MPLS section G-ACH is used, the GAL is added to the packet as
defined in [GAL-GACH], i.e.,  the TTL field SHOULD be set to 1, and
the S-bit of the GAL MUST be set to 1.

mv> tp-gach-gal does not strictly says that.

c/If the MPLS section G-ACH is used/If the G-ACh is associated with an
MPLS Section/

If the G-ACH is associated with an LSP, the GAL is added to the
packet and the LSP label is pushed on top of the GAL as defined in
[GAL-GACH], i.e., the TTL field of the GAL SHOULD be set to 1, and
the S-bit of the GAL MUST be set to 1.

mv> tp-gach-gal does not strictly says that.

c/If the G-ACH/If the G-ACh/

mv> The G-ACh applies to PWs while the text of this document makes
     no reference to that. It would be appropriate to provide to the
     reader a statement on whether or not this DCN Header can be found
     behind an ACH on a PW.

It should be noted that the G-ACH MUST NOT be used to carry user data
and SHALL only be used to carry management or control plane messages.
Procedures that ensure this such as e.g. deep packet inspection are
outside the scope of this specification.

mv> In my view, this requirement does not belong in this document.
     It is already covered in the OAM requirements. It is preferable
     to avoid duplicate requirements moreover written differently.

When a receiver has received a G-ACH packet with the G-ACH Channel
Type set to MCC or SCC, it SHALL look at the PID field of the
extended G-ACH header. If the PID value is known by the receiver it
SHALL deliver the entire packet including the MCC/SCC message to the
appropriate processing entity. If the PID value is unknown, the
receiver SHALL silently discard the received Packet and MAY increment
a counter that counts discarded packets.

c/received a G-ACH packet/received a maintenance packet/
c/with the G-ACH Channel/with the ACH Channel/
c/of the extended G-ACH header/of the DCN Header/
c/received Packet/received packet/

It must be noted that a receiver MUST NOT forward a GAL packet based
on the GAL label as is normally the case for MPLS packets. If the GAL
appears at the bottom of the label stack, it MUST be processed as
described in the previous paragraph.

mv> In my view, this requirement does not belong in this document.
     It is not DCN specific and is already covered in the OAM
     requirements.

Note that there is no requirement for MPLS-TP devices to support IP
or OSI forwarding in the fast or slow paths. Thus, if a message is
received on the MCC or SCC and is not targeted to an address of the
receiving LSR, the LSR MAY discard the message as incorrectly
received.

3. Security Considerations

    The G-ACH provides a virtual link between LSRs and might be used to
    induce many forms of security attack. Protocols that operate over the
    MCN or SCN are REQUIRED to include adequate security mechanisms and
    implementations MUST allow operators to configure the use of those
    mechanisms.

c/The G-ACH/The G-ACh/

4. IANA Considerations

    Channel Types for the Generic Associated Channel are allocated from
    the IANA PW Associated Channel Type registry defined in [RFC4446] and
    updated by [GAL-GACH].

    IANA is requested to allocate two further Channel Types as follows:

    xx  Management Communication Channel (MCC)
    yy  Signaling Communication Channel (SCC)

Adrian Farrel a écrit :
> Hi,
> 
> Looking at the liaison just received, 
> draft-beller-mpls-tp-gach-dcn-01.txt already includes precisely these 
> requirements.
> 
> Obviously, as any changes in gal/gach come about, this draft will be 
> updated to reflect them.
> 
> Thanks,
> Adrian
> ----- Original Message ----- From: "Greg Jones (ITU-T SG 15)" 
> <[email-masked]>
> <[email-masked]>; <[email-masked]>; 
> <[email-masked]>; <[email-masked]>; <[email-masked]>
> Subject: New Liaison Statement, "LS33 - Liaison Response re MPLS-TP 
> support for MCC and SCC"
> 
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 16 Mar 2009 10:43:44 -0000

Hey Martin,

Thanks for comments...

>   reflected in tp-gach-dcn (e.g., those relating to clarifications

Absolutely. Lock-step is hard with different author teams, but the target is 
obvious.

>   Maybe you could add one or two sentences clarifying that point.

I think this is part of the previous point. The ACH TLV used to be defined 
somewhere else, but is now part of gach-gal. I see no reason to disallow 
TLVs, and we are still vascillating over whether end-point IDs and payload 
protocol would be best handled that way.

>   Maybe you could add some text clarifying whether or not

Perhaps you could clarify.
AFAICT, the mechanism can only work between routers that are logically 
adjacent. That is, there must be either a physical link or an LSP already in 
existence between the communicasting routers.
The reason this is a limitation is that we cannot assume any forwarding at 
any CP layer.

So, if the purpose of your question is to discover how PEs might exchange 
targeted LDP messages for PW set-up, the answer is:
PEs wishing to set up PWs using a singaling protocol that uses remote 
adjacencies in the absence of an IP-based control plane network MUST first 
set up an LSP tunnel across the MPLS-TP network. This tunnel can be used 
both to carry the PW once it has been set up, and to provide a DCN for 
control plane communications between the CPs.

Do you think it is necessary to explicitly add this statement, or does it 
follow automatically from the capabilities of the DCN?

Hmmm. So ACH TLVs are not new? The channel type hasn't been partitioned?

Shall we s/extension/generalisation/ ?

>     as it is done, by the way, later in this document.

It is the Abstract. We cannot point to other documents.

The intention is that someone should be able to understand he abstract in a 
stand-alone way. If MPLS-TP was a well-known concept, this would be fine. 
But it is not yet widely discussed and we do not have many RFCs on the 
subject.

Is there anything in this description (not definition) of MPLS-TP that you 
disagree with or that is out of synch with the definitions in the 
requirements and framework documents?

> c/carried on the G-ACH/carried on the G-ACh/

Yes.

> mv> Do you mean that IP capable LSRs must not use that mechanism?

We do not mean MUST NOT, but the intention of this work is to fill a gap 
when IP is not available. It is not our intention to replace IP networking. 
I do not think that you would get such a proposal past the IESG.

My personal view is that there is a strong requirement to use native IP if 
it exists. Why add an extra header to a packet that can be delivered without 
the header?

> c/Generic Associated Channel (G-ACH)/Generic Associated Channel (G-ACh)/

Yes

> c/by the PW Associated Channel Type field of the G-ACH/by the Channel

Yes

> mv> should a reference to the registry be provided (i.e., 4446)?

Yes, thanks for saving the lazy authors the job of recalling the RFC number.

[SNIP]

> mv> Are only LSRs concerned by the solution provided by this document?

Sure thing.
Only LSRs are capbable of forwarding (or processing) MPLS labeled packets.
Or have we invented a new term for an "MPLS-TP label switching device"
LSD may seem attractive to some, but I have often wondered whether some 
people had been over-indulging!

> network (SCN) together known as the data communication network (DCN)

Yes

> mv> Choose either "*on* the G-ACh" or "*over* the G-ACh"

"through" ?  :-)

> call this word the DCN Header?

This folds into the discussion that Loa started.
It says:
Should we use the 4446 registry to indicate the payload protocol
Or should we (as this I-D suggests) use the 4446 registry to say "SCN or 
DCN".

In the latter case, we need some way of identifying the payload protocol.

*Now* in the OAM case, should we consistent.
That is, use the 4446 registry to indicate "OAM" and use a protocol ID word 
to indicate what OAM function is being used?

I don't recall a conclusion to that discussion.

> protocol identifier (PID) field and the remaining 24 bits of the header

Praise be!

> mv> what is the Protocol Identifier TLV?

It has been discussed several times with no obvious conclusion.
It would be an ACH TLV that indicates the payload protocol.

So, look, we now have three possible ways of indicating the payload protocol 
:-(

Perhaps someone who intends implementing this could give some input.

>     suggest to rework the above paragraph only mentioning the sending

Weeeeell.
The point is that the packet cannot (MUST NOT) come from a forwarding 
component.
This definition has been thrust upon us, and although we might not like it, 
we are stuck with it.

> mv> tp-gach-gal does not strictly says that.

It changes in every revision :-)

I would like this document to state the correct behavior for the DCN/SCN 
case, so we will just have to keep updating aas the gach-gal I-D undergoes 
damped harmonic oscillations.

> c/If the MPLS section G-ACH is used/If the G-ACh is associated with an

Yes

> mv> tp-gach-gal does not strictly says that.

Ditto.

>     reader a statement on whether or not this DCN Header can be found

Is a PW not a label switched path?

>     to avoid duplicate requirements moreover written differently.

Sure, but this is nothing to do with OAM.
We have established a new channel (the DCN) that is a subchannel of the 
G-ACh.

This requirement could be conveniently stated in the gach-gal I-D (actually, 
I think it MUST be stated there).

But I have considerable experience of watching vendors with screwed 
implementations trying to claim that it is not their fault that they sent 
user data down the DCN. They have claimed that the specifications didn't 
make it clear. So, let's make it clear and then we can easily point up the 
broken implementations!

Thus, this section provides procedural rules. These are not requirements; 
they are statements about how implementations process packets. I think, 
therefore, it is highly appropriate to state this rule here.

> c/received Packet/received packet/

Yes

>     It is not DCN specific and is already covered in the OAM

Yes, the underlying requirement a generic and should be stated elsewhere. 
(Actually in the gach-gal)

OTOH, it is a behavioral rule for someone implementing the DCN in this way. 
Again, this section needs to state the behavioral rules so that implementers 
can do the right thing. This is (IMHO) entirely appropriate for this 
section.

>    implementations MUST allow operators to configure the use of those

Yes

Many thanks,
Adrian