Network Working Group Wei. Cao
Internet Draft Huawei Technologies
Expires: April 2007 October 16, 2006
IEEE 802.1ah Mode for Ethernet Over MPLS
draft-cao-pwe3-802-1ah-00.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.
This document may only be posted in an Internet-Draft.
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
This Internet-Draft will expire on April 16, 2007.
Cao Expires April 16, 2007 [Page 1]
Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006
Abstract
Ethernet has been widely deployed in metro-networks, and there are
more and more customers select Ethernet PW services. With the
deployment of IEEE 802.1ah network, there is a need to support
802.1ah attachment circuit. Based on the two modes defined in RFC
4448, this document introduces a new Ethernet encapsulation mode to
support the new AC type. This document also describes some scenarios
and procedures pertaining to the new mode. Some considerations
relating to multi-segment PW are also discussed.
Table of Contents
1. Specification of Requirements................................2
2. Introduction.................................................2
2.1. Terminology.............................................3
3. Scenario and Operations for Ethernet PW IEEE 802.3 Mode......4
3.1. Ethernet PW Connection between Two PBBNs................4
4. Details for Ethernet PW 802.1ah Mode.........................5
4.1. Applicability Statement.................................5
4.2. Ethernet PW 802.1ah Mode................................5
4.3. Ethernet-Specific Interface Parameter LDP Sub-TLV.......6
4.4. Encapsulations and Procedures...........................7
5. Security Considerations......................................7
6. IANA Considerations..........................................7
7. Acknowledgments..............................................7
8. References...................................................7
8.1. Normative References....................................7
8.2. Informative References..................................8
Author's Addresses..............................................9
Intellectual Property Statement.................................9
Disclaimer of Validity..........................................9
Copyright Statement............................................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 [RFC2119].
2. Introduction
Ethernet is widely deployed in metro-networks, where 802.1ah is a
conspicuous new technology. Ethernet PW plays an important role in
PWE3, but currently only 802.1q/ad Ethernet ACs are considered. There
Cao Expires April 16, 2007 [Page 2]
Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006
are two modes defined for Ethernet PW in RFC 4448: "raw mode" and
"tagged mode", corresponding to transparent frame tunnel and
forwarding with extra tag-process. Although 802.1ah frame can be
carried with these two modes, if SP wants to support the new emerged
service "Provider Backbone Bridges" well, introducing new mode is
necessary.
802.1ah adds some fields to the 802.1q frame: B-MAC, B-VID and I-
SID. In Provider Backbone Bridge Network (PBBN), forwarding decision
is based on B-MAC and B-VID, while I-SID can be used as a service
delimiter. When two PBBNs are connected through a PW, it may require
PE's NSP inspect 802.1ah frame's B-TAG and I-TAG rather than outmost
tag only. In such cases, PW with 802.1ah mode is suitable. Also
802.1ah mode will be helpful if an Ethernet service wants to span PBN,
MPLS and PBBN.
By introducing 802.1ah mode, frames carried by an Ethernet PW can
have more tags in the encapsulation. Similar to the application
method of the tags in PBT network, one can try to use these extra
tags in PW as below.
- PW multiplex: Currently a PW is identified by a pair of PW labels
allocated by the two end PEs. Since the PW labels are per-platform
MPLS label, if there are many PWs created, PEs have to use a lot
of MPLS labels. In 802.1ah mode, B-TAG/I-TAG can be used to
identify the PW, so multiple Ethernet PWs may be multiplexed
through one pair of PW labels to reduce the number of MPLS label
required.
- MS-PW switching: MS-PW may span multi-domains, and at each S-PE
the PW label will be switched. With 802.1ah mode and more tags in
the encapsulation, one could map BVID into PW label for each
domain, or may use I-SID for PW label switching.
The details of the new application should be further studied.
The new mode will not change the PWE3 Ethernet encapsulation
defined in RFC 4448. It assumes in the remainder of this document the
readers are familiar with RFC 3985 and RFC 4448.
2.1. Terminology
The terminology specified in RFC 3985 and RFC 4026 applies. In
addition, we introduce some terms related to IEEE 802.1ah:
- PBN: Provider Bridge Network
Cao Expires April 16, 2007 [Page 3]
Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006
- PBB: Provider Bridge Backbone
- PBBN: Provider Backbone Bridge Network, often referred as an
802.1ah domain.
- B-VID: Backbone Vlan ID
- I-SID: Service Instance ID
- B-TAG: Backbone TAG field
- I-TAG: Service Instance Tag
3. Scenario and Operations for Ethernet PW IEEE 802.3 Mode
The objective of PWE3 is providing point-to-point connectivity
between two ACs at the edge of a provider network. Considering
802.1ah, the models of linking two PBBNs are described.
3.1. Ethernet PW Connection between Two PBBNs
The following figure shows the typical working context. As shown
in Fig.1, there are two split Mac-in-Mac domains and one MPLS/IP core
networks. Customer's devices are attached to UPE1 and UPE2. Since
there is no direct connection between the two Mac-in-Mac domains, if
the customer needs Ethernet service from UPE1 to UPE2, an Ethernet PW
should be created to provide the connectivity.
<---PWE3 Services --->
--- --------- -----
/ \ / \ / \
+----+ |802 +----+ +----+802 | +----+
---|UPE |MAC-in |--- |NPE | MPLS |NPE |----| MAC-in |UPE |---
| 1 | MAC |.1ah| 1 |network| 2 |.1ah| -MAC | 2 |
+----+Domain1| +----+ +----+ \Domain2+----+
\ / \ / \ /
----- -------- -----
Figure 1. PBBN connected by Ethernet PW
Cao Expires April 16, 2007 [Page 4]
Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006
The PWE3 service is terminated in NPE1 and NPE2. If only
transparent transmission is needed, then there is no extra operation
of the Native Service Processing (NSP) and Ethernet "raw mode" is
enough. However, if the two Mac-in-Mac domains have different
understanding of the B-TAG or I-TAG, some translation work may be
required. For example, the NPE should have to recognize the 802.1ah
encapsulation and has the ability to rewrite B-TAG/I-TAG.
RFC 4448 defines two Ethernet PW modes: "raw mode" and "tagged
mode". Since "tagged mode" only inspects the outermost tag, in this
scenario if NPE needs to rewrite I-TAG, then neither "raw mode" nor
"tagged mode" can satisfy it. So here we introduce a new mode and
call it "802.1ah" mode.
It should be noticed that the NPE process such as rewriting B-
TAG/I-TAG belongs to NSP, and NSP is outside the scope of PWE3. But
it is useful to provide necessary information to PE to identify what
service is been carried and denote the NSP difference.
4. Details for Ethernet PW 802.1ah Mode
4.1. Applicability Statement
The Ethernet PW emulation with 802.1ah mode should allow an "Provider
Backbone Bridges" based service across an MPLS network. It has the
following characteristics in relation to the respective native
services:
- An Ethernet PW connects two PBBN domains, supporting bidirectional
transport of variable length Ethernet frames. It SHOULD be assured
by administrators that both ends of the PW support IEEE 802.1ah.
- An Ethernet PW connects PBN and PBBN, and if B-TAG/I-TAG
insert/remove action should be taken at one side of the PW, at
least the ends to do the process MUST support IEEE 802.1ah.
- For an 802.1ah Ethernet Frame transmitted by an Ethernet PW, B-TAG
or I-TAG or both may be process by NSP at the Ingress or Egress.
The detail function is outside the scope of this document.
- FCS retention, sequencing are the same as defined in RFC4448.
4.2. Ethernet PW 802.1ah Mode
With 802.1ah mode, plus two modes defined in RFC4448, there are
three Ethernet PW modes:
Cao Expires April 16, 2007 [Page 5]
Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006
- Ethernet Tagged Mode, it corresponds to PW type 0x0004.
- Ethernet Raw Mode, it corresponds to PW type 0x0005.
- Ethernet 802.1ah Mode, it corresponds to PW type 0x001A (TBD).
In Ethernet 802.1ah mode, it requires PE have the ability to
recognize 802.1ah frame. The PE may re-write B-TAG/I-TAG content, or
insert/remove B-TAG/I-TAG when needed. If the PE detects a frame in
wrong encapsulation format, PE must discard the frame.
It should be noted that if customer requires Ethernet frames be
transmitted unchanged, PE should use "raw mode" rather than 802.1ah
mode even the frames are encapsulated in 802.1ah format.
4.3. Ethernet-Specific Interface Parameter LDP Sub-TLV
This LDP Sub-Type Length Value [LDP] specifies interface-specific
parameters. When applicable, it MUST be used to validate that the PEs,
and the ingress and egress ports at the edges of the circuit, have
the necessary capabilities to interoperate with each other. The
Interface parameter TLV is defined in [PWE3-CTRL]. RFC 4448 defines
Requested VLAN ID Sub-TLV. Here new Sub-TLVs are specified as follows:
- 0x0D(TBD) Requested PBB I-TAG Sub-TLV
An optional 24-bits value indicates the requested I-TAG. This
parameter MUST be used by a PE that is incapable of rewriting the
IEEE 802.1ah I-TAG on output. If the ingress PE receives this
request, it MUST process the I-TAG correctly at the input to match
the requested I-TAG. If this is not applicable, the PW MUST not be
enabled.
- 0x0E(TBD) Requested PBB B-TAG/I-TAG Sub-TLV
An optional 36-bits value indicates the requested B-TAG and I-TAG.
The 36 bits value is composed of 12 bits B-TAG value and 24 bits I-
TAG value. This parameter MUST be used by a PE that is incapable of
inserting/removing 802.1ah I-TAG on output. If this is no
applicable, the PW MUST not be enabled.
- 0x0F(TBD) Requested I-TAG Filter Sub-TLV
An optional multi-24-bits value indicates the request of filtering
specific I-TAG. In some scenarios, there are more than one I-TAGs
corresponding to one B-TAG in one Ethernet stream that should be
carried by an Ethernet PW. PE can use Requested I-TAG Filter Sub-
Cao Expires April 16, 2007 [Page 6]
Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006
TLV to request remote PE to filter the frames with those specific
I-TAG.
These parameters are applicable only to 802.1ah PW type. The first
two TLVs can not be used together, while they can be used with the
last one.
4.4. Encapsulations and Procedures
The encapsulation specification defined in RFC4448 applies for
802.1ah mode. As described in section 4.6 of RFC4448, the control
word may or may not be needed in different cases. But it is suggested
in this document to use the control word for 802.1ah mode to reduce
the risk brought by ECMP path.
802.1ah mode complies with the procedures described in RFC 4448,
including MTU management, Frame Ordering, Frame Error Processing, etc.
5. Security Considerations
802.1ah mode does not introduce new security problems to Ethernet
pseudowire type.
6. IANA Considerations
The value of new PW type and LDP sub-TLV should be defined.
7. Acknowledgments
I would like to thank Yu Delei for his help on IEEE specifications. I
also wish to acknowledge Yaakov Stein for his suggestions.
8. References
8.1. Normative References
[PWE3-CW] Bryant, S., Swallow, G., and D. McPherson, "Pseudowire
Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS
PSN", RFC 4385, February 2006.
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[PWE3-CTRL] Martini, L., El-Aawar, N., Heron, G., Rosen, E., Tappan,
D., and T. Smith, "Pseudowire Setup and Maintenance using the
Label Distribution Protocol (LDP)", RFC 4447, April 2006.
Cao Expires April 16, 2007 [Page 7]
Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, Multiprotocol
Label Switching Architecture, RFC 3031, January 2001.
[802.3] IEEE802.3-2005, ISO/IEC 8802-3: 2000 (E), "IEEE Standard
for Information technology -- Telecommunications and information
exchange between systems -- Local and metropolitan area networks
-- Specific requirements -- Part 3: Carrier Sense Multiple Access
with Collision Detection(CSMA/CD) Access Method and Physical
Layer Specifications", 2005.
[802.1Q] ANSI/IEEE Standard 802.1Q-2005, "IEEE Standards for Local
and Metropolitan Area Networks: Virtual Bridged Local Area
Networks", 2005.
[802.1ah/D2.20] IEEE P802.1ah/D2.20 Draft Standard for Local and
Metropolitan Area Networks-Virtual Bridged Local Area Networks-
Amendment 6: Provider Backbone Bridges, April, 2006.
8.2. Informative References
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[PWE3-REQ] Xiao, X., McPherson, D., and P. Pate, "Requirements for
Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September
2004.
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[FRAG] Malis, A. and W. Townsley, "PWE3 Fragmentation and
Reassembly", Work in Progress, February 2005.
[FCS] Malis, A., Allan, D., and N. Del Regno, "PWE3 Frame
Check Sequence Retention", Work in Progress, September
2005.
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, November 2000.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026,March 2005.
Cao Expires April 16, 2007 [Page 8]
Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006
Author's Addresses
Cao Wei
Huawei Technologies
Room 1201, Kuike Bld., No.6 Xinxi Rd.,
Shang-di Information Industry Base,
Hai-Dian District Beijing, China
Email: caowayne@huawei.com
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.
Disclaimer of Validity
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.
Cao Expires April 16, 2007 [Page 9]
Internet-Draft draft-cao-pwe3-eth-802.1ah-00 October 2006
Copyright Statement
Copyright (C) The Internet Society (2006).
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.
Cao Expires April 16, 2007 [Page 10]