[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

 Internet Draft                                              David Allan
 Document: draft-allan-mpls-pid-00.txt                   Nortel Networks
 Category: Standards Track                                    April 2003
 
 
 
 
                        MPLS and IP PW Payload ID
 
 
 Status of this Memo
 
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.
 
    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as
    reference material or to cite them other than as "work in progress."
 
    The list of current Internet-Drafts can be accessed at
         http://www.ietf.org/ietf/1id-abstracts.txt
    The list of Internet-Draft Shadow Directories can be accessed at
         http://www.ietf.org/shadow.html.
 
 Copyright Notice
 
    Copyright(C) The Internet Society (2003). All Rights Reserved.
 
 Abstract
 
    This memo defines an MPLS and PW payload ID. It describes how an
    MPLS payload ID may be used to address a number of issues associated
    with proprietary ECMP deployments. It describes how when used with
    PWs permits OAM and control protocols to be multiplexed with a PW.
 
 Sub-IP ID Summary
 
    [to be removed when published]
 
    WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK
 
    Fits in the MPLS, and PWE3.
 
    WHY IS IT TARGETED AT THESE WGs
 
    This draft addresses a number of issues associated with
    instrumenting/controlling MPLS LSPs and PWs in general.
 
 
 
    Allan et.al           Expires October 2003                   Page 1

                       MPLS and IP PW Payload ID
 
 
 1. Introduction
 
    A number of problems have arisen with MPLS due to the deployment of
    core LSRs that perform load sharing for TE link bundles or to
    implement ECMP in LDP networks. Load spreading preserves microflow
    ordering (in varying degrees of granularity) via hashing of some or
    all of the label stack, and if the first nibble of the payload
    suggests an IPv4 packet, may incorporate IP flow details as well.
 
    Load sharing means that OAM flows and diagnostic tools may not fate
    share with an LSP (including PWs). Use of reserved labels to
    distinguish flows may result in the flows having different
    forwarding behavior than the LSP of interest. Use of IP packets in
    non-IP LSPs may have different forwarding behavior than the LSP of
    interest.
 
    Load sharing implies that a defacto payload ID exists in the MPLS
    architecture that impacts the payload carrying ability of any given
    LSP. Under certain circumstances a payload may be misinterpreted as
    IPv4 packet and have forwarding adversely modified.
 
    This document describes an approach to providing an MPLS and IP PW
    payload ID such that:
         - multiprotocol over MPLS and/or PWs may be transported
           without being mis-interpreted by load sharing LSRs. This is
           primarily in the interest of explicitly associating OAM and
           control traffic with LSPs and/or PWs.
         - OAM flows may fate share with the LSP of interest in a load
           sharing environment.
         - An alternative approach to reserved labels is supported such
           that requisite functions may be provided without being
           impacted by load sharing.
         - Commonality of PW control words is exploited for both MPLS
           LSPs and non MPLS PWs.
 
 2. MPLS and PW extended payload ID
 
    MPLS label stack encoding is defined in [RFC3032]. This draft
    defines the following extension to label stack encoding.
 
    When the 'S' bit indicating bottom of stack is set, the payload is
    examined and if the first nibble is 0x08, then the payload may be
    interpreted as an extended payload ID control word. (Note that this
    collides with the current version number assignment for the P
    Internet protocol (PIP) [RFC1621, RFC 1622], and may collide with
    other protocol formats, it remains to be seen if this is an issue).
 
    For non-MPLS PWs configured to use a control word that support the
    extended payload ID control word, the extended payload ID control
    word may be used interchangeably with the normal PW control word.
    The extended PW control word is distinguished via the first nibble
    0x08 value.
 
    Allan                   Expires October 2003                 Page 2

                       MPLS and IP PW Payload ID
 
 
    The format of the extended payload ID control word is common to
    both MPLS LSPs, and PWs (of any variety). The format is:
 
 
     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |1 0 0 0|A|    rsvd.    |   PA  |            Protocol ID        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
    Where:
 
         A       = LSR or PE "Alert"
         Rsvd.   = reserved for future use (== 0)
         PA      = protocol authority for Protocol ID
                         0       = reserved
                         1       = IP protocol number
                         2       = IEEE Ethertype
                         3-15    = reserved
         Protocol ID   = Protocol id of any payload following the
                         extended payload ID control word.
 
    Implementations that support the extended payload ID control word
    MUST, at a minimum, be able to support ICMP echo request/reply [RFC
    792] over IPv4 as payload. Originators of ICMP echo request
    messages use the any address in the non-routable 127./8 address
    range as a destination address. Originators of ICMP echo reply
    messages substitute their own PSN loopback address for the 127./8
    when replying.
 
 3. PW Applicability
 
    The extended payload ID control word allows protocols to be
    multiplexed with PWs and fate share with PW connectivity. This
    would include but not be limited to IP, GTTP [GTTP], Y.1711
    [Y.1711] etc.
 
    When used with PWs, it would permit IP (or other protocol) packets
    to be carried over the PW in a manner opaque to deployed load
    spreading mechanisms. Therefore for ICMP PING, GTTP, Y.1711 or LSP-
    PING [LSP-PING] operations, PDUs will have common forwarding with
    the PW, and sufficient information is transported in the PW to
    permit a PSN return path to be employed.
 
    Normal procedure would be to insert an IP message into the PW (PID
    auth == IP PID, Protocol ID == 4 (IPinIP)[RFC1700]) which would be
    processed by the receiving PE.
 
    This also provides an alternate mechanism to use of the reserved
    label for Y.1711, PID to be assigned by IANA.
 
 
 
    Allan                   Expires October 2003                 Page 3

                       MPLS and IP PW Payload ID
 
    Use of two-legged transactions without a network layer header is
    not explicitly precluded (PW return path).
 
    Support for the Extended payload ID control word may be signaled
    via use of the PWid FEC Element [PWESIG]. Bit 14 of the PW type
    field is used to indicate support for the Extended payload ID
    control word.
         1 = supported
         0 = NOT supported
    Alternately PW support for the Extended payload ID control word may
    be tested for in tunnels via use of ICMP ping in conjunction with
    the extended payload ID CW.
 
 
 4. MPLS Applicability
 
    The extended payload ID control word allows protocols to be
    multiplexed with MPLS LSPs, and fate share with LSPs that do not
    have their payload considered as part of load spreading operations.
    This would include:
         - Load spreading based on the combination of incoming label
           and interface.
         - Load spreading based on hashing any portion of the label
           stack. If the depth of hashing is not configurable, the
           extended PID control word can only guarantee forwarding
           consistency when employed on non-MPLS payload bearing LSPs.
 
    But would NOT include:
         - LSPs where non-MPLS payload (such as IP packet headers) was
           considered when performing load spreading calculations.
         - Use of reserved labels (such as router alert) in conjunction
           with the Extended PID CW. The alert bit in the CW is
           provided as an alternative mechanism.
 
    When used with LSPs (subject to the caveats above), it would permit
    IP (or other protocol) packets to be carried over the LSP in a
    manner opaque to deployed load spreading mechanisms. Therefore for
    ICMP PING,  Generic Tunnel Trace Protocol, Y.1711 or LSP-PING
    operations, PDUs will have common forwarding with the LSP.
 
    The specific scenarios addressed are when an RSVP-TE LSP has a non-
    IP L3PID, and use of Y.1711.
 
    Support for the Extended payload ID control word may be tested for
    in tunnels set up via BGP, RSVP-TE or LDP via use of ICMP ping.
 
 5. MTU Issues
 
    The extended payload ID control word does not include a length
    field (nominally used to distinguish payload from padding when the
    PDU is below the minimum length for Ethernet).
 
 
 
    Allan                   Expires October 2003                 Page 4

                       MPLS and IP PW Payload ID
 
    Protocols carried as payload with the extended PW control word must
    either always be padded to the Ethernet minimum frame size (e.g.
    Y.1711) or be self describing w.r.t. length (e.g. IPv4 [RFC791]).
 
 6. Restrictions
 
    The extended PID SHOULD NOT be used with MPLS LSPs that are PHP'd.
 
 7.  References
 
    [GTTP]       Bonica, R. et.al., "Generic Tunnel Tracing Protocol
                 (GTTP) Specification", IETF Internet Draft, draft-
                 bonica-tunproto-04.txt, February 2003
 
    [LSP-PING]   Kompella et.al., "Detecting Data Plane Liveness", IETF
                 Internet Draft draft-ietf-mpls-lsp-ping-02.txt,
                 September 2003
 
    [PWESIG]     Martini et.al., "Pseudowire Setup and Maintenance using
                 LDP", Internet Draft draft-ietf-pwe3-control-protocol-
                 02.txt, February 2003
 
    [RFC 791]    Postel, J. (editor), "Internet Protocol", IETF
                 RFC 791, September 1981
 
    [RFC 792]    Postel, J., "Internet Control Message Protocol", IETF
                 RFC 792, September 1981
 
    [RFC 1621]   Francis, P., "Pip Near-term Architecture", IETF RFC
                 1621, May 1994
 
    [RFC 1622]   Francis, P., "Pip Header Processing", IETF RFC 1622,
                 May 1994
 
    [RFC 1700]   Reynolds, J., Postel, J., "Assigned Numbers", IETF RFC
                 1700, October 1994
 
    [RFC 3032]   Andersson et.al., "LDP Specification", IETF RFC 3036,
                 January 2001
 
    [Y.1711]     ITU-T Recommendation Y.1711 (2002), "OAM Mechanism for
                 MPLS Networks"
 
 
 8. Author's Address
 
    David Allan
    Nortel Networks              Phone: 1-613-763-6362
    3500 Carling Ave.            Email: dallan@nortelnetworks.com
    Ottawa, Ontario, CANADA
 
 9. Full Copyright Statement
 
 
    Allan                   Expires October 2003                 Page 5

                       MPLS and IP PW Payload ID
 
    "Copyright (C) The Internet Society (2003). Except as set forth
    below, authors retain all their rights.
 
    This document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph
    are included on all such copies and derivative works.  However, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the  purpose of
    developing Internet standards in which case the procedures for
    rights in submissions defined in the IETF Standards Process must be
    followed, or as required to translate it into languages other than
    English.
 
    The limited permissions granted above are perpetual and will not be
    revoked by the Internet Society or its successors or assigns.
 
    This document and the information contained herein is provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
    REPRESENTS (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/