Internet DRAFT - draft-allan-mpls-pid
draft-allan-mpls-pid
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.
