Internet DRAFT - draft-aissaoui-extended-pid
draft-aissaoui-extended-pid
Network Working Group Mustapha Aissaoui
Internet Draft Matthew Bocci
Expiration Date: April 2004 David Watkinson
Alcatel
Andrew G. Malis
Tellabs
October 2003
Extended MPLS/PW PID
draft-aissaoui-extended-pid-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of section 10 of RFC 2026.
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.
Abstract
This draft proposes the extension of the proposed MPLS/PW PID to
include the identification of user protocols and multiple control
plane protocols carried in a PW or MPLS LSP.
Table of Contents
Status of this Memo.............................................1
Abstract........................................................1
Table of Contents...............................................1
1 Conventions used in this document.............................2
2 Introduction..................................................2
Aissaoui, et al. Expires April 2004 [Page 1]
Internet Draft draft-aissaoui-extended-pid-01.txt October 2003
3 Extended MPLS/PW PID..........................................3
3.1 Structure of the Extended MPLS/PW PID......................4
3.2 User-Plane Protocol Identification Details.................4
4 Signaling of the extended MPLS/PW PID.........................5
5 Security Considerations.......................................5
6 Intellectual Property Disclaimer..............................6
7 Appendix A: Application of the Extended MPLS/PW PID to Layer 2
interworking....................................................6
7.1 Interworking Considerations................................8
7.2 Application of the Extended MPLS/PW PID to MPLS/PW OAM.....9
8 References....................................................9
9 Acknowledgments..............................................10
10 Authors' Addresses..........................................10
11 Full Copyright Statement....................................11
1 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.
2 Introduction
There has been much discussion in the PWE3 and MPLS working group
mailing lists about the concept of MPLS or PW protocol identifier
(PID). A number of applications for the MPLS/PW PID have been
identified:
a. The first one has to do with the IP aliasing issue [1]. In
networks where load balancing schemes such as ECMP are used,
the first nibble immediately following the bottom of the label
stack may infer a IPv4 or IPv6 if its value is 4 or 6. Some
ECMP implementations include this nibble in the hashing
mechanism and may attempt to process further information beyond
this nibble if the packet is mistaken for an IP packet. It is
therefore required that non-IP payloads not to infer these two
values. In the specific case of PWE3 applications, this issue
is addressed by forcing the first nibble of the generic control
word or of the preferred control word to a value of zero [1].
However, the SONET PW control word [2] does not comply with
this requirement. The SONET encapsulation addresses this issue
by preceding the SONET control word with a MPLS/PW PID to
disambiguate its payload from an IP packet.
b. The second one has to do with the ability to identify in PE,
MPLS or PW OAM messages, such as Y.1711 [3], LSP-Ping [4], or
VCCV [5]. Y.1711 messages are MPLS control packets, while LSP-
Ping and VCCV are IP control packets. All can be inserted in a
non-IP LSP in the case of PWE3 applications. A PE can make use
Aissaoui, et al. Expires April 2004 [Page 2]
Internet Draft draft-aissaoui-extended-pid-01.txt October 2003
of the MPLS/PW PID to indicate to the remote PE that the
payload is an OAM packet without the need for a special label
value.
c. The third one is about making sure that a MPLS or a PW OAM
packet follows exactly the same path as the user traffic if
ECMP or similar load sharing mechanisms are used in the
network. This is fairly important since the whole idea of OAM
packet is to check the sanity and to troubleshoot the path user
packets follow through the network. The currently proposed MPLS
or PW OAM messages rely on a reserved label value to carry
these messages. For example, LSP-Ping makes use of the router
alert label value while Y.1711 OAM makes use of the OAM alert
label value. In both cases, another label is pushed into the
stack and thus the hashing algorithm of some ECMP
implementations may cause the OAM packet to follow a different
path from the user packet. If a MPLS/PW PID is used instead of
a special label value, this problem can be resolved. A proposal
for MPLS/PW PID to address this issue was made in draft-allan-
mpls-pid-00.txt [6].
This draft proposes to extend the use of the MPLS/PW PID to
identify user plane protocols carried in the LSP/PW payload. The
main application is interworking of different link layers over a
MPLS network, where each data link layer is terminated locally in
a PE. The MPLS/PW PID allows the use of a single multiprotocol PW
between any two user sites. The issues that are resolved by this
method are explained in Appendix A.
Appendix A also discusses the use the MPLS/PW PID to identify
different types of OAM messages in a PW in such a way to address
issues (b) and (c) above.
3 Extended MPLS/PW PID
The proposed structure of the MPLS/PW PID is compatible with the
MPLS payload type identifier in the PWE3 architecture document
[1]. Furthermore, it is compatible with RFC 2684 (Multiprotocol
over ATM), RFC 2427 (Multiprotocol over Frame Relay), and RFC 2878
(Bridging over PPP).
Support for this format of the PID is only needed when there are
multiple protocol types being transmitted over the same PW. It is
unnecessary when there is a single protocol even if this single
protocol multiplexes other protocols.
When only partial support is provided for this PID, the handling
of multiple alternatives referred to in section 3.2 should be
examined.
Aissaoui, et al. Expires April 2004 [Page 3]
Internet Draft draft-aissaoui-extended-pid-01.txt October 2003
3.1 Structure of the Extended MPLS/PW PID
The structure of the proposed MPLS/PW PID is shown in Figure 1:
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| rsvd. | PA | Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rsvd. = reserved for future use (== 0)
PA = protocol authority for the user plane or the control
plane protocol ID
0 = PPP DLL. Reserved for MPLS/PW
control protocol identification.
1 = ISO NLPID (other than 0x80)
2 = IP protocol number
3 = Ethertype
4 = SNAP (ISO NLPID=0x80, e.g., IEEE
802.1 MAC type)
5-15 = reserved
Protocol ID = Protocol ID following the format defined by the
protocol authority identified in PA.
Figure 1: Extended MPLS/PW PID Structure
3.2 User-Plane Protocol Identification Details
The user plane encapsulation follows the procedures in the
NLPID/SNAP encapsulation in RFC 2427 (Multiprotocol over Frame
Relay). Where there are multiple alternatives to identify a
specific protocol, the use of the representation with the lowest
PA possible is required. For example, an IP datagram is
represented using PA=1 and an ISO NLPID=0xCC.
PA=1: ISO NLPID value other than 0x80 (32 bits)
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| rsvd. | PA=1 | ISO NLPID |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following ISO NLPID values are supported using this
configuration:
0x81 ISO CLNP
0x82 ISO ESIS
0x83 ISO ISIS
0xCC IP
0xCF PPP
PA=2, IP protocol number (32 bits)
Aissaoui, et al. Expires April 2004 [Page 4]
Internet Draft draft-aissaoui-extended-pid-01.txt October 2003
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| rsvd. | PA=2 | IP Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PA=3: Ethertypes (32 bits)
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| rsvd. | PA=3 | Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PA=4: SNAP protocols such as 802.1 MAC types and private protocols
(64 bits)
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| rsvd. | PA=4 | NLPID=0x80 | OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI (cont'd) | PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IEEE 802.1 bridged protocols are carried in the MPLS or PW payload
using PA=4 and the 802.1 organization code of 0x00-80-C2 in the
OUI field in the SNAP header. The following are the PID field
values used to identify the different bridged protocols:
with preserved FCS w/o preserved FCS Media
------------------ ----------------- --------------
0x00-01 0x00-07 802.3/Ethernet
0x00-02 0x00-08 802.4
0x00-03 0x00-09 802.5
0x00-04 0x00-0A FDDI
0x00-0B 802.6
0x00-0D Fragments
0x00-0E BPDUs as defined by
802.1(d) or 802.1(g)
0x00-0F Source Routing BPDUs
4 Signaling of the extended MPLS/PW PID
This section is for further study.
5 Security Considerations
This draft does not introduce any new security considerations to
MPLS.
Aissaoui, et al. Expires April 2004 [Page 5]
Internet Draft draft-aissaoui-extended-pid-01.txt October 2003
6 Intellectual Property Disclaimer
This document is being submitted for use in IETF standards
discussions.
7 Appendix A: Application of the Extended MPLS/PW PID to Layer 2
interworking
Note: this appendix is not intended to be part of the
specification of the MPLS/PW PID. It is only provided to highlight
an application of the MPLS/PW PID. The content of this appendix
will be moved to a separate draft in the next revision of this
draft.
Figure 2 shows an example of interworking of different link layers
over MPLS.
|CE1|--FR--|PE1|----MPLS----|PE2|--Ethernet--|CE2|
\ /
\ /
\ /
|PE3|
|
ATM
|
|CE3|
Figure 2: Interworking of different link layers over MPLS
Each AC can carry multiple higher layer protocols. This type of
interworking can be achieved in three different ways. Each method
is valid and has its own advantages and disadvantages.
1. Extend one link layer to the remote PE:
for example, the ATM link layer between CE3 and PE3 in
Figure 2 can be extended to PE2 using the PWE3 ATM-MPLS
encapsulations [9]. In PE2, the ATM PW is terminated and
the corresponding ATM AAL5 payload is reconstructed. Then
ATM and Ethernet link layers are interworked and the
corresponding PID fields are translated. The same thing
can be done for the FR link between CE1 and PE1 using a FR
PW towards PE2. Note that extending the Ethernet link
layer makes only sense if it is done all the way to the
ATM and FR CEs using a bridged encapsulation over the FR
and ATM links, and Ethernet PWs between the PEs.
Otherwise, PE1 and PE3 will need to insert a (fake) MAC
address for the FR and ATM interfaces on CE1 and CE3 in
order to communicate with CE2.
Aissaoui, et al. Expires April 2004 [Page 6]
Internet Draft draft-aissaoui-extended-pid-01.txt October 2003
This method has the advantage of reusing existing PW
encapsulations specified in the PWE3 working group. It
also simplifies the interworking with MPLS since it does
not require the identification of the higher layer
protocols carried in an AC.
However, it makes the assumption that a PE will need to
terminate multiple L2 over MPLS encapsulations even if it
does not support those L2 interface types. For example,
PE2 might only have Ethernet and MPLS interfaces and not
ATM interfaces. In order to use this method, it will need
to terminate and process ATM PWs as specified in [9].
2. Set up multiple pseudo-wires for each AC:
This method is described in [8]. In this case, each link
layer is terminated locally in a PE which inspects each
packetÆs PID to select the PW dedicated to each protocol
type. Therefore, multiple PWs need to be set up for each
AC. In the case where IP packets are routed over the AC
while all other protocols are bridged over the AC, this
method reduces to the set up of 2 parallel pseudo-wires
for each AC: an IP PW and an Ethernet PW.
This method has the advantage of using the current PW
model of inferring the protocol carried in the PW from the
label value. In other words, each PW carries only one
protocol type.
The disadvantage of this method is that it requires the
association of multiple PWs to a single AC. This is a
change to the current forwarding behavior of a PW. That
is, the traffic received on a AC is forwarded over a PW
based on the attachment circuit and the PID in the link
layer encapsulation.
There are also cases where one wants to avoid splitting
the path of the carried protocols. For example, the CE in
Figure 2 could be a device of another service provider who
runs IS-IS as its IGP while the rest of the traffic is IP.
In normal operation, a failure of the datapath is detected
by the IS-IS routing plane since routing packets follow
the same path as user packets. If the IP PW fails while
the IS-IS PW is still up, there is no way to let the IS-IS
routing know about the failure except by tearing down the
IS-IS PW. The tearing down of a group of PWs when one of
them fails is not desirable for other types of user
protocols who do not have such kind of dependency.
3. Set up a multiprotocol PW and translate the PID:
In this method, each link layer is terminated locally in a
PE which inspects each received packet in an AC and
translates the link layer PID into a PW PID. The PW PID
has the format proposed in Section 3 of this document.
Aissaoui, et al. Expires April 2004 [Page 7]
Internet Draft draft-aissaoui-extended-pid-01.txt October 2003
This method allows the creation of a single multiprotocol
PW to carry all protocols in an AC.
Consider the example of the traffic between CE1 and CE2 in
Figure 2. The CE device could belong to a service provider
running IS-IS as its IGP. The interworking here is between
an Ethernet interface and an rfc2427 routed FR DLCI with
IP and ISIS routing traffic. The ISIS routing traffic can
be carried over the same PW as the IP traffic by using an
extended PID with PA=1 and NLPID=0x83. The NLPID is
interworked to 802.3 LLC on the Ethernet side of the PW by
adding the appropriate LLC of FEFE03 using the same
mapping as defined in FRF 8.1 [10].
This method has the advantage of requiring a single PW to
carry multiple user protocols over MPLS. It maintains the
same path for both user and control plane protocols of the
customer of the network. Finally, it provides a consistent
operation with existing FR-ATM service interworking
deployments.
The disadvantage of this method is that the PE needs to
inspect the received traffic on a PW packet by packet in
order to translate the PID. Note however that the PW
forwarding paradigm is not changed. Forwarding is still
based on the label and the attachment circuit for each
direction respectively. PID translation can be viewed as
part of payload manipulation.
7.1 Interworking Considerations
Regardless of which of the 3 above methods is used to perform
interworking of different link layers over MPLS, there are two
orthogonal issues to resolve:
a. Identification of multiple higher-layer protocols:
When a CE multiplexes multiple protocols in a single AC, it
indicates the protocol type in a protocol identifier (PID)
field in the link layer encapsulation. For example, RFC 2684
specifies the format for this field for an ATM/AAL5 link layer.
A PE examines the PID of each packet received in a AC to either
select the PW dedicated to this protocol (method 2) or to
translate the link layer PID into a PW PID(method 3). In the
case of method 1, the PE performs a translation of the PID
between two link layers, for instance ATM/AAL5 and Ethernet in
the example above.
b. L3 protocol dependency on the type of link layer:
Consider again the example of IS-IS traffic and IP traffic
carried between CE1 and CE2 in Figure 2. The operation of ISIS
Aissaoui, et al. Expires April 2004 [Page 8]
Internet Draft draft-aissaoui-extended-pid-01.txt October 2003
over a PW can treat the link as a broadcast link or a point-to-
point link. When it is point-to-point (i.e., only one CE
device on the Ethernet end), the procedures in draft-ietf-isis-
igp-p2p-over-lan [11] will apply. When it is broadcast, there
can be multiple CE routers on the Ethernet AC. The preferred
choice in this particular case is to change the FR AC to
bridged encapsulation and use an Ethernet PW. This will allow
the FR attached CE (CE2) to properly participate when presented
with packets with the three multicast MAC addresses AllISs,
AllL1ISs, and AllL2ISs. If the FR AC is not or cannot be
changed to bridged encapsulation, the Ethernet attached PE will
need to assume that all ISIS packets received across the PW
should be prepended with the AllISs destination MAC or dig into
the packet to determine the MAC to use based on the packet
type. The procedures for ARP Mediation [12] need to be applied
to determine a source MAC address.
7.2 Application of the Extended MPLS/PW PID to MPLS/PW OAM
In order to address issues (b) and (c) in Section 2, the MPLS/PW
PID can be used to identify an MPLS/PW OAM message carried in a
PW. This is an alternative to the router alert label value in LSP
Ping/VCCV and to the OAM alert label value in Y.1711 MPLS OAM.
An IP control packet (LSP Ping/VCCV) inserted in a PW is
identified by including the MPLS/PW PID just below the bottom of
the MPLS label stack as explained in [5]. The PA field is set to 0
to indicate a MPLS/PW control plane protocol. The PID field is a
PPP DLL and is set to the value indicating an IPv4 or IPv6 packet.
Similarly, a Y.1711 OAM message is identified through a PA=0 and a
specific value of the PPP DLL to be assigned by IANA.
8 References
[1] Bryant, S., "The PWE3 Architecture", draft-ietf-pwe3-arch-
06.txt, October 2003.
[2] Malis, A., et al.,öSONET/SDH Circuit Emulation over Packet
(CEP)ö, draft-ietf-pwe3-sonet-01.txt, January 2003.
[3] ôOAM Mechanisms for MPLS Networksö, ITU-T Recommendation
Y.1711, November 2002.
[4] Kompella, K., et al., ôDetecting MPLS Data Plane Livenessö,
draft-ietf-mpls-lsp-ping-03.txt, June 2003.
Aissaoui, et al. Expires April 2004 [Page 9]
Internet Draft draft-aissaoui-extended-pid-01.txt October 2003
[5] Nadeau, T., et al., ôPseudo Wire (PW) Virtual Circuit
Connection Verification (VCCV), draft-ietf-pwe3-vccv-00.txt,
July 2003.
[6] Allan, D., ôMPLS and IP PW Payload IDö, draft-allan-mpls-pid-
00.txt, April 2003.
[7] Moreels, J., et al., ôMulti-protocol encapsulation over
MPLSö, draft-moreels-multiproto-mpls-00.txt, October 2002.
[8] Sajassi, A., et al., ôL2VPN Interworkingö, draft-sajassi-
l2vpn-interworking-01.txt, March 2003.
[9] Martini, L., et al.,ô Encapsulation Methods for Transport of
ATM Cells/Frame Over IP and MPLS Networksö, draft-ietf-pwe3-
atm-encap-03.txt, October 2003.
[10] Frame Relay Forum, ôFRF 8.1 - Frame Relay / ATM PVC Service
Interworking Implementation Agreementö, February 2000.
[11] Shen, N., et al., ôPoint-to-point operation over LAN in link-
state routing protocolsö, draft-ietf-isis-igp-p2p-over-lan-
03.txt, September 2003.
[12] Shah, H., et al., ôARP Mediation for IP interworking of Layer
2 VPNö, draft-shah-ppvpn-arp-mediation-02.txt, July 2003.
9 Acknowledgments
The authors like to acknowledge the contribution to this work by
Jeremy de Clercq, John Fischer, Johan Moreels, Stefaan De Cnodder,
Dimitri Papadimitriu, Dave Allan, and Stewart Bryant. Some of the
drivers and applications for this draft were initially presented
in draft-moreels-multiproto-mpls [7]. The idea of a Protocol
Authority (PA) field was originally proposed in draft-allan-mpls-
pid [6].
10 Authors' Addresses
Mustapha Aissaoui
Alcatel
600 March Rd
Kanata, ON, Canada. K2K 2E6
Email: mustapha.aissaoui@alcatel.com
Matthew Bocci
Alcatel
Voyager Place, Shoppenhangers Rd
Maidenhead, Berks, UK SL6 2PJ
Email: matthew.bocci@alcatel.co.uk
Aissaoui, et al. Expires April 2004 [Page 10]
Internet Draft draft-aissaoui-extended-pid-01.txt October 2003
David Watkinson
Alcatel
600 March Rd
Kanata, ON, Canada. K2K 2E6
Email: david.watkinson@alcatel.com
Andrew G. Malis
Tellabs
2730 Orchard Parkway
San Jose, CA 95134
phone:+1 408-383-7223
email:Andy.Malis@tellabs.com
11 Full Copyright Statement
"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.
Aissaoui, et al. Expires April 2004 [Page 11]
