Network Working Group Luca Martini
Internet Draft Ali Sajassi
Intended status: Standards Track Cisco Systems Inc.
Expiration Date: August 2008
February 2008
802.1ah Ethernet Pseudowire
draft-martini-pwe3-802.1ah-pw-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
An Ethernet Pseudowire (PW) is used to carry Ethernet/802.1ah frames
over an MPLS network. This enables service providers to offer
"emulated" Ethernet services over existing MPLS networks. This
document specifies the encapsulation of 802.1ah Ethernet Frames
Martini & Sajassi [Page 1]
Internet Draft draft-martini-pwe3-802.1ah-pw-02.txt February 2008
within a pseudo wire. It also specifies the procedures for using a PW
to provide a "point-to-point Ethernet" service.
Table of Contents
1 Specification of Requirements ........................ 2
2 Acronyms and Abbreviations ........................... 2
3 Introduction ......................................... 3
4 Applicability Statement .............................. 3
5 Ethernet 801.1ah I-tagged Tagged Mode encapsulation .. 4
6 Generic Encapsulation Procedures ..................... 5
6.1 The Control Word ..................................... 6
6.2 QoS Considerations ................................... 7
7 Intellectual Property Statement ...................... 8
8 Full Copyright Statement ............................. 8
9 IANA Considerations .................................. 9
10 Normative References ................................. 9
11 Author Information ................................... 10
1. Specification of Requirements
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. Acronyms and Abbreviations
* Service Instance TAG (I-TAG): A 4-byte tag identified by its own
Ethertype value defined in IEEE 802.1ah.
* Service Instance Identifier (I-SID): A field of the Service
Instance TAG which identifies the service instance within an
802.1ah domain.
* Service Instance Drop Eligibility Indicator (I-DEI): A field of
the I-TAG which identifies the Service Instance Drop Eligibility
of the frame in the 802.1ah (PBBN) domain.
* Service instance priority code point (I-PCP): A field of the I-
TAG which identifies the service instance priority of the frame
in the 802.1ah (PBBN) domain.
* I-tagged Service Interface: A 802.1ah (PBBN) interface type over
which an I-TAG immediately follows the destination and source MAC
addresses in the header of the Ethernet frames.
Martini & Sajassi [Page 2]
Internet Draft draft-martini-pwe3-802.1ah-pw-02.txt February 2008
3. Introduction
A new Ethernet Pseudowire (PW) is used to carry 802.1ah Ethernet [AH]
frames over an Multi Protocol Label Switched [RFC3031] network. In
addressing the issues associated with carrying an 802.1ah Ethernet
frame over a Public Switched Network (PSN), this document assumes
that a Pseudowire (PW) has been set up by using a control protocol
such as the one as described in [RFC4447]. The design of Ethernet
Pseudowire described in this document conforms to the pseudo wire
architecture described in [RFC3985]. It is also assumed in the
remainder of this document that the reader is familiar with RFC3985
and [RFC4448].
Two distinct types of Ethernet PW are described in [RFC4448]: a raw
mode Ethernet PW (PW type 5) and a 802.1Q tagged mode Ethernet PW (PW
type 4). This documents describes a method to encapsulate 802.1ah
tagged frames into MPLS which will be called a 801.1ah I-tagged
Ethernet PW.
4. Applicability Statement
The Ethernet PW emulation allows a service provider to offer a "I-SID
to I-SID" Ethernet based service across an MPLS packet switched
network (PSN).
In keeping with the PW architecture, we wish to minimize the
processing work needed to forward the packet along the PW. One
important point is to use the MPLS label as the demultiplexer to
determine where the Ethernet packet needs to be forwarded at the
egress PE. For this reason a PW of type 5 (Raw Ethernet) is not
suitable for this application as it would use the I-SID as the
demultiplexer/service delimiter, and not the MPLS PW label.
The 801.1ah I-tagged Ethernet PW has the following characteristics in
relationship to the respective native service:
- Ethernet 801.1ah I-tagged PW connects two Ethernet I-Tag aware
forwarders, supporting bi-directional transport of variable
length Ethernet frames. The ingress Native Service Processing
(NSP) function strips the preamble and FCS from the Ethernet
frame and transports the frame in its entirety across the PW. The
egress NSP function receives the Ethernet frame from the PW and
regenerates the preamble and FCS before forwarding the frame to
the attachment circuit. Since FCS is not being transported across
the PW, payload integrity transparency may be lost. The OPTIONAL
methods described in [RFC4720] can be used to achieve payload
integrity transparency on Ethernet 801.1ah I-tagged PWs.
Martini & Sajassi [Page 3]
Internet Draft draft-martini-pwe3-802.1ah-pw-02.txt February 2008
- I-tag rewrite can be achieved by NSP at the egress PE which is
outside the scope of this document.
- The 801.1ah I-tagged Ethernet PW only supports homogeneous
Ethernet frame type across the PW; both ends of the PW must I-
tagged. Heterogeneous frame type support achieved with NSP
functionality is outside the scope of this document.
- 801.1ah I-tagged Ethernet status notification is provided using
the PW Status TLV in the LDP status notification message. Loss of
connectivity between PEs can be detected by the LDP session
closing, or by using [RFC5085] mechanisms. The PE can convey
these indications back to its attached Remote System.
- The maximum frame size that can be supported is limited by the
PSN MTU minus the MPLS header size, unless fragmentation and
reassembly is used [RFC4623].
- The packet switched network may reorder, duplicate, or silently
drop packets. Sequencing MAY be enabled in the 801.1ah I-tagged
Ethernet PW to detect lost, duplicate, or out-of-order packets on
a per-PW basis.
- The faithfulness of an 801.1ah I-tagged Ethernet PW may be
increased by leveraging Quality of Service features of the PEs
and the underlying PSN. (see "QoS Considerations" section)
5. Ethernet 801.1ah I-tagged Tagged Mode encapsulation
The Ethernet frame will be encapsulated according to the procedures
defined later in this document.
Martini & Sajassi [Page 4]
Internet Draft draft-martini-pwe3-802.1ah-pw-02.txt February 2008
AC PW
Forwarder
------------ ------------
| Data | | Data |
|----------| |----------|
|Other TAGs| |Other TAGs|
|----------| |----------|
| I-TAG | ----| | I-TAG |
|----------| | |----------|
| SA MAC | | | SA MAC |
|----------| | |----------|
| DA MAC | | | DA MAC |
------------ | |----------|
+--> |Encap (CW)|
| |----------|
+--> | PW Label |
|----------|
|PSN tunnel|
------------
If the PE detects a failure on the Ethernet physical port, or the
port is administratively disabled, it MUST send PW status
notification message for all PWs associated with the port.
If the PE is notified that the I-SID has been removed , or is in a
down state it MUST notify the egress PE using the PW status
procedures defined in [RFC4448]. The method by which the PE learns
that the I-SID in no longer in service is outside the scope of this
document.
This mode uses service-delimiting I-tags to map input Ethernet frames
to respective PWs and it corresponds to PW type 0x001F "Ethernet I-
Tagged Mode". [Note: Pending IANA allocation]
6. Generic Encapsulation Procedures
When the NSP/Forwarder hands a frame to the PW termination function:
- The preamble (if any) and FCS are stripped off.
- The control word as defined in the "The Control Word" section is,
if necessary, prepended to the resulting frame. The conditions
under which the control word is or is not used are specified
below.
Martini & Sajassi [Page 5]
Internet Draft draft-martini-pwe3-802.1ah-pw-02.txt February 2008
- The proper Pseudowire demultiplexor (PW Label) is prepended to
the resulting packet.
- The proper tunnel encapsulation is prepended to the resulting
packet.
- The packet is transmitted.
The way in which the proper tunnel encapsulation and pseudo wire
demultiplexor are chosen depends on the procedures that were used to
set up the pseudo wire.
The tunnel encapsulation depends on how the MPLS PSN is setup. This
can include no label, one or more labels. The proper pseudo wire
demultiplexor is an MPLS label whose value is determined by the PW
setup and maintenance protocols.
When a packet arrives over a PW the tunnel encapsulation, if still
present, is stripped off. Then the PW demultiplexor MPLS label is
used to determine how to process the packet, no other information
from the packet is required. If the control word is present, it is
processed and stripped off. If needed, the I-SID in the I-tag is re-
written according to a provisioned value. The resulting frame is then
handed to the appropriate Forwarder/NSP. Regeneration of the FCS is
considered to be an NSP responsibility.
6.1. The Control Word
When carrying Ethernet over an MPLS backbone, sequentiality may need
to be preserved. The OPTIONAL control word along the guidelines of
[RFC4385] is defined here, and addresses this requirement.
Implementations MUST support sending no control word, and MAY support
sending a control word. If the control word is not used all the
functionality defined in [RFC4385] is not available. In particular
the PW packet may be mistakenly recognized as an IP packet by PSN
devices that use the first nibble in the packet to identify it's
content. This problem is only significant if the PSN contain equal
cost load sharing links that use the first nibble in the packet to
identify it's content, and a destination MAC address starting with
0x4 or 0x6 as it first byte is used. In the case of the I-tag PW, it
would be sufficient to void using the prefix 0x4 or 0x6 in the
provider mac address space.
A PW carried over an MPLS PSN that uses the contents of the MPLS
payload to select the ECMP path SHOULD employ the PW MPLS Control
Word, if strict packet ordering is required.
Martini & Sajassi [Page 6]
Internet Draft draft-martini-pwe3-802.1ah-pw-02.txt February 2008
In all cases the egress router must be aware of whether the ingress
router will send a control word over a specific virtual circuit. This
may be achieved by configuration of the routers, or by signaling, as
defined in [RFC4447].
The control word 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 0| Reserved | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the above diagram the first 4 bits MUST be set to 0 to indicate PW
data. The rest of the first 16 bits are reserved for future use.
They MUST be set to 0 when transmitting, and MUST be ignored upon
receipt.
The next 16 bits provide a sequence number that can be used to
guarantee ordered frame delivery. The processing of the sequence
number field is OPTIONAL.
The sequence number space is a 16 bit, unsigned circular space. The
sequence number value 0 is used to indicate that the sequence number
check algorithm is not used. The sequence number processing algorithm
is found in [RFC4385].
6.2. QoS Considerations
The ingress PE MAY consider the 802.1ah Service Instance Drop
Eligible (I-DEI) Indicator and of the Service Instance Priority Code
Point (I-PCP) I-tag header when determining the value to be placed in
a QoS field of the encapsulating protocol (e.g., the EXP fields of
the MPLS label stack). In a similar way, the egress PE MAY consider
the QoS field of the MPLS (e.g., the EXP fields of the MPLS label
stack) protocol when queuing the frame for CE-bound.
A PE MUST support the ability to carry the Ethernet PW as a best
effort service over the MPLS PSN. The 802.1ah bits are kept
transparent between PE devices, regardless of the QoS support of the
PSN.
A PE may support additional QoS support by means of one or more of
the following methods:
Martini & Sajassi [Page 7]
Internet Draft draft-martini-pwe3-802.1ah-pw-02.txt February 2008
-i. One COS per PW End Service (PWES), mapped to a single COS PW
at the PSN.
-ii. Multiple COS per PWES mapped to a single PW with multiple
COS at the PSN.
The PW guaranteed rate at the MPLS PSN level is PW service provider
policy based on agreement with the customer, and may be different
from the Ethernet physical port rate.
7. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
8. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
Martini & Sajassi [Page 8]
Internet Draft draft-martini-pwe3-802.1ah-pw-02.txt February 2008
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9. IANA Considerations
This document uses a new PW type. IANA already maintains a registry
of name: "MPLS Pseudowire Types Registry" defined by RFC4446. The
following value is suggested for assignment:
PW type Description Reference
------- ----------------------------------------------- ---------
0x001F Ethernet 802.1ah I-Tagged Mode TBD
10. Normative References
[AH] IEEE 802.1, "IEEE P802.1ah/D3.4 - Virtual Bridged
Local Area Networks Amendment 6: Provider Backbone
Bridges", March 10, 2007.
[RFC3031] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol
Label Switching Architecture", RFC3031, January 2001
[RFC3985] Bryant, et al., "PWE3 Architecture",
RFC3985, March 2005.
[RFC4447] "Transport of Layer 2 Frames Over MPLS", Martini, L.,
et al., rfc4447 April 2006.
[RFC4448] L. Martini, Et. al "Encapsulation Methods
for Transport of Ethernet over MPLS Networks", RFC4448,
April 2006
[RFC4385] "PWE3 Control Word for use over an MPLS PSN", S.
Bryant, G. Swallow, L. Martini, D. McPherson, RFC4385,
February 2006
[RFC5085] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection
Verification (VCCV), A Control Channel for Pseudowires",
RFC5085 December 2007.
[RFC4720] A. Malis, D. Allan, N. Del Regno, "Pseudowire
Emulation Edge-to-Edge (PWE3) Frame Check Sequence
Retention", RFC4720, November 2006
[RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-
Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August
Martini & Sajassi [Page 9]
Internet Draft draft-martini-pwe3-802.1ah-pw-02.txt February 2008
2006.
11. Author Information
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
e-mail: lmartini@cisco.com
Ali Sajassi
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
e-mail: sajassi@cisco.com
Martini & Sajassi [Page 10]