Internet DRAFT - draft-balus-pwe3-ip-pseudowire
draft-balus-pwe3-ip-pseudowire
PWE3 Working Group
Internet Draft
Expires: April 2005
Himanshu Shah Florin Balus
Ciena Networks Mike Loomis
Jeff Sugimoto
Nortel Networks
Mustapha Aissaoui
Alcatel Mircea Pisica
Infonet
October 2004
IP Pseudowire Encapsulation
draft-balus-pwe3-ip-pseudowire-01.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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.
Abstract
This document proposes a PW encapsulation specific to IP packets,
the IP Pseudowire, following the architectural principles defined in
[PWE3 Architecture]. This proposal introduces an optional CW for IP
encapsulation. Note that when the inclusion of a control word is not
negotiated, the IP PW uses the encapsulation described in [RFC3032].
Balus et.al Expires Jan 2005 Page 1
draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005
Table of Contents
1. Conventions used in this document.............................2
2. Introduction and Requirements.................................2
3. Reference Model...............................................3
4. IP PW Encapsulation...........................................4
5. Support for PW OAM............................................5
6. Support for non-IP payload....................................6
7. Signaling of the IP PW........................................7
8. Security Considerations.......................................7
9. Changes from the previous version.............................7
10. Acknowledgements..............................................7
11. Intellectual Property Rights Notices..........................7
12. References....................................................7
13. Authors' Addresses............................................8
1. Conventions used in this document
The keywords "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 and Requirements
This document defines the encapsulation and the motivators for using an
optional CW for IP pseudowire. In this model, the AC circuits are
terminated at each PE, and only the IP payload is transported across the
PSN using a PW header. Two solutions using the IP PW encapsulation
are described in [ARP Mediation] and [IPLS]. Multi-hop pseudowire could be
also another application for the concepts described in this draft.
The requirements for an IP PW vary depending on the behavior expected
from end user application, and sometimes by how much the layer 2 media
characteristics were used to achieve said behaviour. For instance,
deterministic path forwarding, connection tracing, discard priorities
and congestion notifications are typical L2 attributes, which often
benefit a native, end-to-end service encapsulated within it. In the
context of an IP PW, these characteristics may need to be reflected to
preserve current SLAs.
Specifically concerning deterministic path forwarding in IP/MPLS networks,
when no CW is used, the IP PW uses the encapsulation described in
[RFC3032], virtually indistiguishable from the IP over MPLS encapsulation,
mapped based on the IP FEC. Current ECMP algorithms used by the MPLS LSRs
may perform deep packet inspection and loadshare the IP over MPLS packets
based on the IP addresses from the customer IP header. As a result, when
the CW is not present, the packets on an IP PW may be loadspread across
multiple backbone paths compromising the deterministic path forwarding.
In this scenario potential OAM packets (see [VCCV]) may be forwarded
consistently on a different path than most of the IP PW packets. This
could cause challenges for troubleshooting and operational changes to the
network administrator looking to migrate their L2VPN networks to an IP PW
Balus et.al Page 2
draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005
transport. Network operators that relied on L2 mechanisms to provide this
functionality may expect to preserve this behavior in IP PWs. Similarly,
some end user applications rely on native L2 congestion notifications or
discard priority markings for QoS treatment or even SLA reporting.
Clearly, not all end user applications using an IP PW will have an
identical set of requirements. Typically an internet access service has
less requirements from its layer 2 transport media, when compared to a
SLA-based, L2VPN service. An IP PW must be flexible enough to satisfy the
loose requirements of the basic application, but offer the optional tools
to address the strict requirements of the more demanding one.These
requirements typically include:
¸ Enable the use of PW in-band OAM with or without ECMP
¸ Distinguish an IP PW frame from a regular IP/MPLS frame for
consistent forwarding of user frames in a PSN using ECMP
¸ The option to reflect important layer 2 service characteristics
This document proposes an IP PW encapsulation that includes an optional
IP control word. The new encapsulation enables the use of PW OAM tools
already defined in [VCCV] while offering the mechanisms for preserving the
characteristics of the end-to-end L2 service. This provides an efficient
transport of IP PDUs between ACs in environment where ECMP is deployed but
the lack of determinism of ECMP, and diagnostic complexity is not desired
for this specific service. The document describes also how the proposed
solution addresses the case of an MPLS backbone running ECMP so that the
data and OAM packets follow the same path throughout the backbone.
3. Reference Model
The following diagram represents the reference model used to
describe the services emulated by the IP PW, based on the concepts
outlined in [PWE3 Architecture].
|<------------- Emulated L2 Service -------------->|
| |
| |<----- IP Pseudo Wire ----->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V(IP/)X AC +----+ +----+(IP/)Y AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|..........IP PW1............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|..........IP PW2............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
Customer | | Customer
Edge 1 | | Edge 2
| |
native X service native Y service
Figure 1: PWE3 IP PW Network Reference Model
Balus et.al Page 3
draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005
In figure 1, X and Y represent two Attachment Circuits, both
upporting an IP payload. An IP PW is used to provide PSN transport
between the two ACs. It is important to note as a general rules that
for the direction CE1 to CE2 the ingress PE, PE1, should map all the
IP/X frames to IP/PW encapsulation described in section 4. The rest
of the frame types MUST be discarded with the exceptions noted in
section 7. Same is valid in the reverse direction (CE2->CE1) on PE2.
4. IP PW Encapsulation
This document introduces an OPTIONAL Control Word (CW) in front of
the customer IP payload. This will address the requirements
described in section 2, ensuring that the IP PW data packets follow
the same path with the PW OAM ones. Also the presence of this CW
allows for additional flexibility in maintaining the Layer 2 service
characteristics.
The IP PW Control Word follows the guidelines and the bit format
described in [Martini L2CIRC] section 3.1 - see figure 3 below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd |B|F|D|0|FRG| Length | Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Customer IP PDU |
| " |
| " |
| " |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IP PW Control Word
- The first 4 bits are reserved for further use. They MUST be set to
(0000) upon transmitting. They ensure the IP PW data packets are
differentiated from normal IP packets in the MPLS ECMP case. Or in other
words they will follow the same path with the PW OAM ones.
- The next 4 bits (4 to 7) MAY be used to provide flexible support for
transport-specific treatments for any given AC type:
. Bit 4 (B) used to signal Backward Congestion Indication (BCI)
This bit could be used to alleviate possible congestion situation
related to differences in speed between ACs located at the two sides
of an IP PW: e.g. Ethernet/ATM AC X --> FR AC Y.
. Bit 5 (F) used to signal Forward Congestion Indication (FCI)
. Bit 6 (D) used to indicate the Discard Priority (DP)
If the transmitting PE does not support the processing of the above
flags, it MUST set them to 0. If the receiving PE does not support the
Balus et.al Page 4
draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005
processing of the flags it MAY ignore them upon reception.
. Bit 7 is reserved and must be set to 0.
- FRG field (bits 8,9) MAY be used to provide support for PW Fragmentation
to address MTU mismatch. The usage of these bits is compliant with the
procedure described in [FRAG]. Note that the usage of PW fragmentation
could be negotiated using the parameter id described in section 4 of
[FRAG]. Alternatively, fragmentation at IP Layer could be used - see
section 3 of [FRAG]. In the latter case the packet is fragmented at the
ingress PE and reassembled just at the IP Destination device - i.e. the
egress PE does not get involved. As such this option could be enabled by
provisioning just at the ingress PE.
- Length field (bits 10 to 15) MAY be used (see [Martini L2CIRC] section
3.1) in conjunction with the padding of short IP PW payloads (i.e. 40
Bytes) when the link layer protocol on the related PSN links requires a
minimum frame length: i.e. minimum payload for Ethernet is 64 bytes. If
the total length of the IP payload plus the CW (4 bytes) plus the 2
labels (8 bytes) is less than 64 bytes then the Length field indicates
the total length of the L2 payload (i.e. IP payload+12 bytes). Otherwise
the length field must be set to zero. The egress PE will remove the
padding and it will restore the frame to its original size.
Alternatively, the Length field from the IP header could be used to
address this issue. In this case the padding will be removed just at the
IP destination.
- The next 16 bits provide a sequence number that can be used to guarantee
ordered packet delivery. The processing of the sequence number field is
OPTIONAL and a value of 0 is used to indicate an unsequenced packet.
This Sequence number SHOULD be compliant with the rules defined in
[Martini L2CIRC] see section 3.1.1 and 3.1.2.
5. Support for PW OAM
[VCCV] defines a set of OAM tools (i.e. Ping, BFD) to be used for
any type of PW encapsulation. One of the methods proposed to identify
the associated OAM flows (see Section 4.1 of [VCCV]) suggests the use
of the following format:
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 = 0 | PA=0 | PPP DLL Proto Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: VCCV OAM Encapsulation
The first nibble (0001) together with PPP DLL Protocol Number field is
used to identify the OAM flows. This will enable, for the IP PW, the
unrestricted use of OAM mechanisms common to other PW types.
Balus et.al Page 5
draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005
6. Support for non-IP payload
As a general rule PE1 and PE2 will discard the incoming non-IP payloads
on ACs X and Y. Still there could be exceptions from the above rule: e.g.
if CE1 and CE2 are using IS-IS for routing protocol, the IP PW might be
required to transport this non-IP payload between PE1 and PE2.
To achieve the above goal, it is proposed to extend the PWE3 Payload Type
Identifier defined in [PWE3-CW] 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 = 0 | PA=X | Payload Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IP PW Encapsulation used non-IP payload exceptions
The value PA=0 is reserved for PW OAM messages (VCCV PING, BFD). Values
other than zero are used to identify user packets which are not IP packet.
For example, PA=1 (ISO protocol) and the corresponding ISO NLPID code
points could be used to provide support for transporting IS-IS frames over
an IP PW:
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=0x83 |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7. Signaling of the IP PW
A 15 bit quantity containing a value is used as part of the PWiD and
Generalized Id FECs to identify the type of PWs - see [PWE3-CTRL] sections
5.1 and 5.2. To signal the IP PW we propose the usage of the value 0x000b
already assigned in [IANA PWE3]section 2 for IP Layer2 Transport.
The negotiation of the control word complies with the procedure described
in [PWE3-CTRL] section 5.4.2.
No new TLVs, Interface parameters are required for now.
8. Security Considerations
To be completed later.
9. Changes from the previous version
- Improved the Abstract and Introduction to clarify the goal of the draft
- Switched section "Support for PW OAM" (now 5, previously 4) with "IP PW
Encapsulation" (now 4, previously 5).
- Comments in section 4: on the usage of BE(fragmentation) and Lenght bits
- Changed the format in section 6 to allign to the newly proposed PTI
Balus et.al Page 6
draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005
10. Acknowledgements
The authors would like to thank David Allan, Hamid Ould-Brahim, for
their helpful discussions and feedbacks.
11. Intellectual Property Rights Notices.
This document is being submitted for use in IETF standards discussions.
12. References
[PWE3 Architecture] "PWE3 Architecture", draft-ietf-pwe3-arch-
07.txt, IETF work in progress, March 2004
[ARP Mediation] Shah, Himanshu "ARP Mediation for IP Interworking of
Layer 2 VPN", draft-shah-l2vpn-arp-mediation-03.txt, IETF work in
progress, October 2003
[IPLS] Shah,Himanshu "IP-Only LAN Service", draft-ietf-l2vpn-ipls-01.txt,
IETF work in progress, May 2004
[RFC3032] "MPLS Label Stack Encoding" IETF RFC 3032
[2547] Rosen, E. Rekhter, Y., "BGP/MPLS VPNs", IETF RFC 2547,
March 1999
[VCCV] Nadeau et.al., "Pseudo Wire (PW) Virtual Circuit Connection
Verification (VCCV)", draft-ietf-pwe3-vccv-02.txt, February 2004
[RFC2427] RFC 2427, "Multiprotocol Interconnect over Frame Relay"
[RFC2684] RFC 2684, "Multiprotocol Encapsulation over ATM Adaptation
Layer 5"
[Martini L2CIRC] Martini et.al. "Encapsulation Methods for Transport
of Layer 2 Frames Over IP and MPLS Networks", draft-martini-
l2circuit-encap-mpls-07.txt, IETF Work in Progress, June 2004
[Martini L2TRANS] Martini et.al. "Transport of Layer 2 Frames Over
MPLS", draft-martini-l2circuit-trans-mpls-14.txt, IETF Work in
Progress, June 2004
[FR PW] Kawa et.al. "Frame Relay over Pseudo-Wires", draft-ietf-
pwe3-frame-relay-02.txt, IETF Work in Progress, February 2004
[ATM PW] Martini et.al. "Encapsulation Methods for Transport of ATM
Over IP and MPLS Networks", draft-ietf-pwe3-atm-encap-05.txt, IETF
Work in Progress, April 2004
[PWE3-CTRL] Martini et.al. "Pseudowire Setup and Maintenance using
LDP", draft-ietf-pwe3-control-protocol-07.txt, IETF Work in
Progress, June 2004
Balus et.al Page 7
draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005
[IANA PWE3] Martini, Townsley "IANA Allocations for pseudo Wire Edge
to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-04.txt
(work in progress), April 2004
[IANA PPP] IANA Point-to-Point Protocol Field Assignments, June 28,2004
http://www.iana.org/assignments/ppp-numbers
[RCF3032] RFC 3032 Rosen, et al., "MPLS Label Stack Encoding", January
2001
[PWE3-CW] Bryant-McPherson, "PWE3 Control Word"
draft-bryant-mcpherson-pwe3-cw-00.txt, July 2004
12. Authors' Addresses
Florin Balus
Nortel Networks
3500 Carling Ave.
Ottawa, Ontario, CANADA
e-mail: balus@nortelnetworks.com
Jeff Sugimoto
Nortel Networks
3500 Carling Ave.
Ottawa, Ontario, CANADA
e-mail: sugimoto@nortelnetworks.com
Mike Loomis
Nortel Networks
Billerica, MA
Himanshu Shah
35 Nagog Park,
Acton, MA 01720
Email: hshah@ciena.com
Mircea Pisica
Infonet Services Corporation
Brussells, Belgium
Mustapha Aissaoui
Alcatel
600 March Rd
Kanata, ON, Canada. K2K 2E6
Email: mustapha.aissaoui@alcatel.com
Full copyright statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Balus et.al Page 8
draft-balus-pwe3-ip-pseudowire-01.txt Expires January 2005
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 copyrights defined in the
Internet 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 are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (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.
Balus et.al Page 9
