One document matched: draft-allan-pw-o-pbt-00.txt
Internet Draft David Allan
Document: draft-allan-pw-o-pbt-00.txt Florin Balus, Nigel Bragg
Category: Standards Track Nortel
February 2006
Pseudo Wires over Provider Backbone Transport
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 June 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo describes architecture and procedures for the operation of
pseudo wires over provider backbone transport (PBT).
1. Introduction
Provider backbone transport offers a mechanism to permit scalable p2p
trunks to be configured or signaled in an Ethernet subnetwork. Such
trunks are suitable to function in the role of PSN in the PWE3
architecture.
2. Terminology
In addition to well understood GMPLS terms, this memo uses
terminology from IEEE 802.1 and introduces a few new terms:
Allan et.al Expires August 2006 Page 1
Pseudo Wires over Provider Backbone Transport
B-MAC Backbone MAC
B-VID Backbone VLAN ID
B-VLAN Backbone Virtual LAN
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
PBT Provider Backbone Transport
RTP Real time protocol
SA Source Address
VID VLAN ID
VLAN Virtual LAN
3. PWoPBT architecture
PBT permits Ethernet bi-directional p2p trunks to be configured
across an Ethernet subnetwork. These trunks can be either configured
by management or signaled as described in [FEDYK]. Frequently more
than one diversely routed trunk is set up to form a protection
group, the most common instantiation being 1:1 protection switching.
+---------------------+ +-------------------------+
| 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 |
+---------------------+ +-------------------------+
| Data-Link |------------->| Data-link |
+---------------------+ +-------------------------+
| Physical |------------->| Physical |
+---------------------+ +-------------------------+
Figure 1. PWE3 architecture illustrating role of PBT
Figure 1 illustrates the role of PBT in the PWE3 architecture [PW-
ARCH}. Where PBT Ethernet PDUs are carried directly over an Ethernet
PHY, the PBT, data-link and physical layers are effectively a single
layer from the point of view of control and management.
Allan et.al. Expires August 2006 Page 2
Pseudo Wires over Provider Backbone Transport
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.
+----------+ +--------+
|PW payload| | PW OAM |
+----------+ +--------+
| |
0000 0001 +--------------+
\ / | LDP |
+-------------------+ +--------------+
| PW CW | | TCP |
+-------------------+ +--------------+ +--------------+
| PW label | | IP | |802.1ag/Y.1731|
+-------------------+ +--------------+ +--------------+
| | |
=0x8847 =0x0800 =TBD
\ | /
/+-------------------------------------------------+
/ | etype |
/ +-------------------------------------------------+
/ | VLAN |
802.1Q+-------------------------------------------------+
header| SA-MAC |
\ +-------------------------------------------------+
\ | DA-MAC |
\+-------------------------------------------------+
Figure 2: Multiplexing of PW bearer, PW OAM, PW control & trunk
OAM over PBT trunk
Further, control, bearer and OAM PDUs inherently share fate with the
PBT trunk 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 current
working path of the protection group. Further the PW service may
directly inherit availability status from the trunk 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 trunk may appear as a single IP hop. 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 trunk and inherit the QoS
characteristics of the trunk directly.
PBT trunks/protection groups may interconnect two U-PEs, a U-PE to
an S-PE, an S-PE to an S-PE. Connecting a U-PE to diverse S-PEs is
for further study.
Allan et.al. Expires August 2006 Page 3
Pseudo Wires over Provider Backbone Transport
4. Signaling Procedures
4.1 Adjacency Establishment and Session Initialization
PW control assumes an a-priori existence of one or more PBT
protection groups between a given pair of PEs.
One hello adjacency will be established between any two PEs per PBT
protection group. The preferred method of indicating the transport
address of the PE is implicit (source address in the Hello
exchange). A PE implements only one transport IP address. It is
common to all PBT trunk terminations. This is typically the PE
loopback address.
LDP extended discovery is used over the working path of the PBT
protection group.
The label space indicated in the LDP Link Hello message MUST be the
per-platform label space.
4.2 Signaling Procedures
Once the Hello adjacency has been established, LDP session
initialization proceeds as per [RFC 3036].
Label exchange procedures are as per [PWE-CONTROL] for single
segment pseudo wires and as per [MS-PW] for multi-segment pseudo
wires.
4.3 Fault scenarios
Failure of a single PBT trunk in the protection group will not
disrupt either the bearer path or the control adjacency. Failure of
all trunks 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.
4.4 Interworking MS-PWs
PBT introduces no new procedures into the interworking of MS-PWs. It
simply takes the role of a PSN Tunnel in one or more segments. Bi-
directional PBT trunks are consistent with the requirement for both
directions of an MS-PW to transit common S-PE devices.
5. OAM Procedures
5.1 Capability Indication
OAM capability indication procedures as per [VCCV] is used
unmodified.
Allan et.al. Expires August 2006 Page 4
Pseudo Wires over Provider Backbone Transport
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 required 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 congruency with the PW
layer cannot be guaranteed.
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.
6. Security Considerations
The use of PBT as a PSN introduces no new security vulnerabilities to
the PWE architecture.
7. References
[FEDYK] GMPLS Control of Ethernet IVL Switches, IETF Internet
Draft, draft-fedyk-gmpls-ethernet-ivl-01.txt, March 2006
[RFC 3036] LDP Specification, IETF RFC 2026, January 2001
[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 Internet Draft, Pseudowire
Setup and Maintenance using the Label Distribution
Protocol, June 2005
[MS-PW] Dynamic Placement of Multi Segment Pseudo Wires, IETF
Internet Draft, draft-ietf-pwe3-dynamic-ms-pw-00.txt,
December 2005
[VCCV] Pseudo Wire Virtual Circuit Connectivity Verification
(VCCV), IETF Internet Draft, draft-ietf-pwe3-vccv-
07.txt, August 2005
8. Author's Address
Allan et.al. Expires August 2006 Page 5
Pseudo Wires over Provider Backbone Transport
Dave Allan
Nortel Networks Phone: 1-613-763-6362
3500 Carling Ave. Email: dallan@nortel.com
Ottawa, Ontario, CANADA
Florin Balus
Nortel Networks Phone: 1-613-768-4997
3500 Carling Ave. Email: balus@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
9. 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.
10.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.
11.Copyright Statement
Allan et.al. Expires August 2006 Page 6
Pseudo Wires over Provider Backbone Transport
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.
12.Acknowledgments
The authors would like to thank Dinesh Mohan for his contributions to
this document.
| PAFTECH AB 2003-2026 | 2026-04-23 07:01:21 |