The MPLS WG Archive

[Danny McPherson <danny@tcb.net>]

This is unquestionably germane to the MPLS WG.  Please provide comments here
or on the pwe3@ietf.org mailing list.

Thanks!

-danny

------ Forwarded Message
From: Danny McPherson <danny@tcb.net>
Date: Fri, 16 May 2003 17:59:59 -0600
To: <pwe3@ietf.org>
Subject: CW & MPLS "PID"


The second issue gating progress with the PWE3, and the architecture draft
specifically, that needs to be resolved relates to the design of the Control
Word and its relationship to any MPLS protocol identification mechanism.

Please provide feedback (of all sorts) to the following summary on the list
within the next week if you've got something to say.  We intend to move
forward shortly.

Thanks,

Stewart/Danny


==================
Section 5.4.3 of the current WG Architecture document mandates that if the
CW is used the encoding MUST be as follows:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  PID  | Flags |FRG|  Length   | Sequence Number               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The draft suggests the use of the value 0, to distinguish it from
IP which uses the values 4 and 6.

After the San Francisco meeting proposals were made to the list
specifying a more general MPLS PID mechanism that used a value
of 1 in bits 0..3 to indicate that the rest of the longword
contained a protocol identifier drawn from a registry that
allowed the following payload to be identified. The purpose
of the identifier was to support the transport of OAM messages
and to allow any PW payload that could not, for some reason,
conform to the requirement that bits 0..3 = 0 to operate correctly
over an ECMP MPLS network.

There is some concern from the MPLS WG as to the extent to which
they will support an MPLS PID, and it is suggested that the PWE3
work needs to be self contained.  This needs to be future investigated.

For all the payload design groups EXCLUDING the SONET and TDM
groups there seems to be some consensus for the following wording:

 >5.4.3. PW over MPLS Generic Control Word
 >
 >   To allow accurate packet inspection in an MPLS PSN, and to operate
 >   correctly over MPLS PSNs that have deployed equal-cost multiple-path
 >   load-balancing a PW packet MUST NOT alias an IP packet.  IP packets
 >   are carried in MPLS label stacks without any protocol identifier.
 >   Historic values of the IP version number [RFC791] [RFC1881] are
 >   therefore used to distinguish between IP and non-IP MPLS payloads.
 >
 >   To disambiguate the PW from an IP flow the PW SHOULD employ either
 >   the generic PW control word shown in Figure 12, or an MPLS payload
 >   type identifier.  Note that an MPLS payload with bits 0..3 = 4 is an
 >   IPv4 packet and an MPLS payload with bits 0..3 = 6 is an IPv6 packet.
 >
 >
 >         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 0|          Specified by PW Encapsulation                |
 >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >
 >        Figure 12: Generic PW Control Word
 >
 >
 >   The PW set-up protocol determines whether a PW uses a control word.
 >   When a control word is used, it SHOULD have the following preferred
 >   form:
 >
 >
 >         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 0| Flags |FRG|  Length   | Sequence Number               |
 >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >
 >        Figure 13: MPLS Preferred Control Word
 >

and

 >5.4.4. MPLS Payload Identifier
 >
 >   If technical considerations result in a PW control word that may
 >   alias an IP packet, the control word SHOULD be preceded by an MPLS
 >   payload type identifier.
 >
 >   For reference the MPLS payload type identifier [TBD] is defined as
 >   follows:
 >
 >          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|  reserved             | PPP DLL Protocol Number       |
 >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >         |           As defined by PPP DLL protocol definition           |
 >         |                                                               |
 >         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >
 >        Figure 14: MPLS Payload Type Identifier

This is the proposal put forward by George Swallow and is a subset of
Dave Alan's proposal except for the sense of one bit.

Figure 12 allows CWs that followed the Martini design to be grandfathered
and due to the values found in a practical network, the Single ATM VCC Cell
Encapsulation conforms to Figure 11.

Figure 14 specifies a MPLS Payload identifier that is sufficient for PWE3
purposes (including the support of OAM messages), and yet is sufficiently
general that other groups can likely make any extensions that they find
necessary.

The questions are:

EXCLUDING any TDM/SONET specific issues is this CW design agreeable to
the PWE3 WG?

Is the MPLS payload identifier design acceptable to the group proposing
OAM/VCCP mechanisms, and if not, what constraints does it place on
future related work?

Is the MPLS payload identifier design acceptable to the MPLS WG as
the basis of a future mechanism should that be required?

If so, is it acceptable to the MPLS WG that PWE3 incorporate this
design within its normative documents in order to make progress?

[Note that this message will be forwarded to the MPLS WG mailing list.]




------ End of Forwarded Message