Internet Draft David Allan
Internet-draft: draft-allan-pw-o-pbt-03.txt Nigel Bragg
Informational Hamid Ould-Brahim
Nortel
Jose Luis Pena
Luis Perez Roldan
Telefonica
Himanshu Shah
Ciena
Nurit Sprecher
Nokia Siemens Networks
July 2007
Carrying PWE3 Pseudo Wires over
Provider Backbone Transport
(PBB-TE, 802.1Qay)
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/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 in April 2007.
Copyright Notice
Copyright (C) The Internet Trust (2007).
Allan et.al December 2007 Page 1
Pseudo Wires over Provider Backbone Transport
Abstract
Provider Backbone Transport (PBT, known as well as PBB-TE and
progressed in IEEE as 802.1Qay [802.1Qay]) provides a mechanism
where native Ethernet point-to-point tunnels can be configured or
signaled across a provider-based Ethernet network [FEDYK]. PWE3
architecture defines a mechanism, called pseudowires, that emulates
the essential attributes of a layer-2 and layer-1 service over a
Packet Switched Network (PSN). This draft describes the architecture
and procedures where Pseudowires are carried across PBT tunnels. In
this proposal PBT tunnels are used as the PSN.
1. Introduction
Provider Backbone Transport (PBT, known as well as PBB-TE and
progressed in IEEE as 802.1Qay) provides a mechanism where native
Ethernet point-to-point tunnels can be configured or signaled across
a provider-based Ethernet network [FEDYK]. PWE3 architecture defines
a mechanism, called pseudowires, that emulates the essential
attributes of a layer-2 and layer-1 service over a Packet Switched
Network (PSN). This draft describes the architecture and procedures
where Pseudowires are carried across PBT tunnels. In this proposal
PBT tunnels are used as the PSN.
2. Acronyms
B-MAC Backbone MAC
B-VID Backbone VLAN ID
B-VLAN Backbone Virtual LAN
BEB Backbone Edge Bridge
BCB Backbone Core Bridge
C-MAC Customer MAC
C-VID Customer VLAN ID
C-VLAN Customer Virtual LAN
DA Destination Address
LLC Logical Link Control
MAC Media Access Control
PBB Provider Backbone Bridge
PBB-TE Provider Backbone-Bridging Traffic Engineering
PBT Provider Backbone Transport
RTP Real time protocol
SA Source Address
VID VLAN ID
VLAN Virtual LAN
3. Architecture
Allan et.al. December 2007 Page 2
Pseudo Wires over Provider Backbone Transport
Figure 1 illustrates the role of PBT in the PWE3 architecture [PW-
ARCH]. Figure 2 describes the data-plane for PWoPBT.
+---------------------+ +-------------------------+
| Payload |------------->| Raw payload if possible |
/=====================\ +-------------------------+
H Payload Convergence H-----------+->| Flags, seq #, etc. |
H---------------------H / +-------------------------+
H Timing H---------/--->| RTP |
H---------------------H / +-------------+ |
H Sequencing H----one of | |
\=====================/ \ | +-----------+
| PW Demultiplexer |---------+--->| PW service label |
+---------------------+ +-------------------------+
| PSN Convergence |------------->| Not needed |
+---------------------+ +-------------------------+
| PSN |------------->| PBT Tunnel |
+---------------------+ +-------------------------+
| Data-Link |------------->| Data-link |
+---------------------+ +-------------------------+
| Physical |------------->| Physical |
+---------------------+ +-------------------------+
Figure 1: PWE3 architecture illustrating role of PBT
When the physical layer is Ethernet, the data-link and physical
layers are effectively a single layer from the point of view of
control and management.
The PWoPBT architecture takes advantage of the fact that the
Ethernet LLC permits multiple protocols to be simultaneously
multiplexed over a PBT protection group. This permits both MPLS/PW
payload/PDUs and IP control and OAM PDUs to be multiplexed together.
+-ATM +-PING
+-Ethernet +-BFD
+-FR +-ETHOAM
+-HDLC |
+-PPP |
+-SaTOP |
| (etc.) |
+----------+ +--------+
|PW payload| | PW OAM |
+----------+ +--------+
| |
0000 0001 +--------------+
\ / | LDP |
Allan et.al. December 2007 Page 3
Pseudo Wires over Provider Backbone Transport
+-------------------+ +--------------+
| PW CW | | TCP |
+-------------------+ +--------------+ +--------------+
| PW label | | IP | |802.1ag/Y.1731|
+-------------------+ +--------------+ +--------------+
| | |
=0x8847 =0x0800 =0x8902
\ | /
/+-------------------------------------------------+\
/ | etype | \
/ +-------------------------------------------------+ \
/ | VLAN | PBT
802.1Q+-------------------------------------------------+ PSN
header| SA-MAC | /
\ +-------------------------------------------------+ /
\ | DA-MAC | /
\+-------------------------------------------------+/
Figure 2: Multiplexing of PW bearer, PW OAM, PW control & tunnel
OAM over PBT tunnel
Further, control, Ethernet PW packets and OAM PDUs inherently share
fate with the PBT tunnel or (where used) protection group
simplifying the job of proactive monitoring of connectivity. Where a
protection group is used control, OAM and bearer traffic is
forwarded on the currently active path of the protection group.
Frequently more than one diversely routed tunnel is set up to form a
protection group, the most common instantiation being 1:1 protection
switching. There may be multiple (even protected) tunnels between a
pair of PEs and only one will be used for PW signaling. Note that
out-of-band signaling can as well be used (such as through the IP
route between the PEs
Further the PW may directly inherit availability status from the
tunnel or protection group.
In addition to the regular IP Infrastructure that may be established
to support PSN Control Plane (routing, GMPLS signaling) exchanges, a
PBT tunnel may appear as a single IP hop away. The IP control
channel allows the mode of operation to be directly analogous to
channel associated signaling. PW labels offered over the signaling
channel are directly bound to the PBT tunnel and inherit the QoS
characteristics of the tunnel directly. A priority may be set to the
control packets.
4. Signaling Procedures
In the context of control plane for PW over PBT, RFC4447 can be used
with no new extensions. Indeed, one targeted LDP hello adjacency
will be established between any two PEs connected by at least one
PBT tunnel or through an IP route. A PE implements only one
Allan et.al. December 2007 Page 4
Pseudo Wires over Provider Backbone Transport
transport IP address that is common to all PBT tunnel terminations.
This is typically the PE loopback address.
LDP extended discovery is used over the currently active path of the
PBT protection group (or using the IP route). In a fault free
network this will be the working path.
The label space indicated in the LDP Link Hello message MUST be the
per-platform label space.
Label exchange procedures are as per [PW-CONTROL] for single segment
pseudo wires and as per [MS-PW] for multi-segment pseudo wires.
PBT tunnels/protection groups may interconnect two T-PEs, a T-PE to
an S-PE, an S-PE to an S-PE/T-PE. PW control plane assumes an a-
priori existence of a PBT protection group between a given pair of
PEs.
4.1 Fault scenarios
Failure of a single PBT tunnel in the protection group will not
disrupt either the bearer path or the control adjacency. Failure of
all tunnels in a protection group or the failure of a PE at a
terminating end to a protection group will disrupt the service. If
the network has not been completely severed by link failures, PBT
may be able to recover connectivity prior to expiration of the LDP
hold timer.
5. OAM Procedures
5.1 Capability Indication
OAM capability indication procedures as per [VCCV] and extended in
[MOHAN] are used unmodified.
5.2 Control Channel
In-band VCCV may be used for both SS and MS PWs without
modifications to procedures described in [VCCV] and [MS-PW].
5.3 VCCV BFD
For a single segment PW, use of VCCV BFD is not necessary as the PW
is 1:1 congruent with the transporting PBT protection group (which
does not implement load spreading such as ECMP) so the PBT OAM
effectively instruments connectivity for the set of PWs carried.
For MS-PWs where a least one segment transits a non PBT network such
as ECMP/LDP, VCCV BFD may be used as PSN OAM since congruency with
the PW layer cannot be guaranteed.
Allan et.al. December 2007 Page 5
Pseudo Wires over Provider Backbone Transport
5.4 VCCV-PING
Normally the return path for a VCCV-PING reply is the PW in the
reverse direction. This is indicated by LSP-PING reply mode 2. It is
also possible to indicate that the reply traverse each segment of a
MS-PW by indicating a reply mode of 3 (use of router alert in the
reply message) although this only slightly modifies the return path
congruency for pure PBT architectures, and is of primary use in
decoupling the return path from the PW in other PSN types.
5.5 VCCV-ETHOAM
[MOHAN] proposes the use of [802.1ag] and [Y.1731] OAM PDUs in
conjunction with the VCCV channel. In this scenario MEPs are co-
located with the PW end points and for MS-PWs, MIPs are co-located
with the S-PEs.
6. Others
PBT tunnels introduce no new procedures into the multi-segment
Pseudowire architecture (MS-PW). It simply takes the role of a PSN
Tunnel in one or more segments. Bi-directional PBT tunnels are
consistent with the requirement for both directions of an MS-PW to
transit common S-PE devices.
7. Security Considerations
The use of PBT as a PSN introduces no new security vulnerabilities
to the PWE architecture.
8. References
[FEDYK] GMPLS Control of Ethernet, IETF Internet Draft, draft-
fedyk-gmpls-ethernet-pbt-01.txt, October 2006
[MOHAN] VCCV Extension for Ethernet OAM, IETF Internet Draft
draft-mohan-pwe3-vccv-eth-01.txt, January 2007
[MS-PW] Dynamic Placement of Multi Segment Pseudo Wires, IETF
Internet Draft, draft-ietf-pwe3-dynamic-ms-pw-02.txt,
October 2006
[PW-ARCH] Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,
IETF RFC 3985, March 2005
[PW-CONTROL] Pseudowire Setup and Maintenance using the Label
Distribution Protocol, IETF RFC 4447, April 2006
[RFC 3036] LDP Specification, IETF RFC 3036, January 2001
[VCCV] Pseudo Wire Virtual Circuit Connectivity Verification
(VCCV), IETF Internet Draft, draft-ietf-pwe3-vccv-
12.txt, January 2007
Allan et.al. December 2007 Page 6
Pseudo Wires over Provider Backbone Transport
[Y.1731] Y.1731 (2006), ITU-T Recommendation, OAM functions and
mechanisms for Ethernet based networks
[802.1ag] Connectivity Fault Management, IEEE 802.1ag draft 6.1,
work in progress.
[802.1Qay] Virtual Bridged Local Area Network, Provider Backbone
Bridge Traffic Engineering, IEEE 802.1Qay, work in
progress.
9. Author's Address
Dave Allan
Nortel Networks Phone: 1-613-763-6362
3500 Carling Ave. Email: dallan@nortel.com
Ottawa, Ontario, CANADA
Nigel Bragg
Nortel Networks UK Limited Phone +44 (0) 1279 40 2052
London Road, Harlow, Essex, Email: nbragg@nortel.com
CM17 9NA, UK
Hamid Ould-Brahim
Nortel Networks Phone: 1-613-765-3418
3500 Carling Ave. Email: hbrahim@nortel.com
Ottawa, Ontario, CANADA
Jose Luis Pena
Telefonica I+D Phone: 34-91-337-4579
Emilio Vargas 6. Email: sedano@tid.es
28043 Madrid. SPAIN
Luis Perez Roldan
Telefonica I+D Phone: 34-91-337-4668
Emilio Vargas 6. Email: lperez@tid.es
28043 Madrid. SPAIN
Himanshu Shah Phone: 978-489-2196
Ciena Email: hshah@ciena.com
35 Nagog Park,
Acton, MA 01720
Nurit Sprecher Phone: +972 9 7751229
Nokia Siemens Networks, Email: nurit.sprecher@nsn.com
GmbH & Co. KG
Research, Technology and Platform
Industry Environment,
Carrier Ethernet and Transport
3 Hanagar St. Neve Ne'eman B
45241 Hod Hasharon, Israel
Allan et.al. December 2007 Page 7
Pseudo Wires over Provider Backbone Transport
10. 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.
11. 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, 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 THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
12. Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
13.Acknowledgments
The authors would like to thank Dinesh Mohan for his contributions
to this document.
Allan et.al. December 2007 Page 8