Internet Draft David Allan, Nigel Bragg Document: draft-allan-pw-o-pbt-02.txt Nortel Category: Standards Track February 2007 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 April 2007. Copyright Notice Copyright (C) The Internet Trust (2007). 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 tunnels to be configured or signaled in an Ethernet subnetwork. Such tunnels are suitable to function in the role of PSN in the PWE3 architecture. The forwarding mechanisms utilized by PBT are progressing at IEEE 802 under the title "Provider Backbone Bridging- Traffic Engineering (PBB-TE)". 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and Allan et.al Expires August 2007 Page 1 Pseudo Wires over Provider Backbone Transport "OPTIONAL" in this document are to be interpreted as described in RFC 2119. In addition to well understood GMPLS terms, this memo uses terminology from IEEE 802.1 and introduces a few new terms: 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 PBT Provider Backbone Transport RTP Real time protocol SA Source Address VID VLAN ID VLAN Virtual LAN 3. Changes since previous version 1) Clarifications with respect to label spaces and protection groups added. 2) References updated. 4. PWoPBT architecture PBT permits Ethernet bi-directional p2p tunnels to be configured across an Ethernet subnetwork. These tunnels can be either configured by management or signaled as described in [FEDYK]. Frequently more than one diversely routed tunnel 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 | +---------------------+ +-------------------------+ Allan et.al. Expires August 2007 Page 2 Pseudo Wires over Provider Backbone Transport | 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. 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 | +-------------------+ +--------------+ | PW CW | | TCP | +-------------------+ +--------------+ +--------------+ | PW label | | IP | |802.1ag/Y.1731| +-------------------+ +--------------+ +--------------+ | | | =0x8847 =0x0800 =TBD \ | / /+-------------------------------------------------+\ / | 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 Allan et.al. Expires August 2007 Page 3 Pseudo Wires over Provider Backbone Transport Further, control, bearer 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. Further the PW service 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. 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. PBT tunnels/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. 5. Signaling Procedures 5.1 Adjacency Establishment and Session Initialization PW control assumes an a-priori existence of a PBT protection group between a given pair of PEs. One hello adjacency will be established between any two PEs. 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 tunnel terminations. This is typically the PE loopback address. LDP extended discovery is used over the currently active path of the PBT protection group. 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. 5.2 Signaling Procedures Once the Hello adjacency has been established, LDP session initialization proceeds as per [RFC 3036]. Label exchange procedures are as per [PW-CONTROL] for single segment pseudo wires and as per [MS-PW] for multi-segment pseudo wires. 5.3 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 Allan et.al. Expires August 2007 Page 4 Pseudo Wires over Provider Backbone Transport 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.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 tunnels are consistent with the requirement for both directions of an MS-PW to transit common S-PE devices. 6. OAM Procedures 6.1 Capability Indication OAM capability indication procedures as per [VCCV] and extended in [MOHAN] is used unmodified. 6.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]. 6.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. 6.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.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. 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- Allan et.al. Expires August 2007 Page 5 Pseudo Wires over Provider Backbone Transport 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 [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. 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 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 Allan et.al. Expires August 2007 Page 6 Pseudo Wires over Provider Backbone Transport 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. Expires August 2007 Page 7