--- 1/draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt 2010-05-03 17:11:49.000000000 +0200 +++ 2/draft-ietf-ccamp-gmpls-ethernet-pbb-te-04.txt 2010-05-03 17:11:49.000000000 +0200 @@ -1,70 +1,76 @@ Internet Draft Don Fedyk, Alcatel-Lucent Category: Standards Track Himanshu Shah, Force10 Networks -Expiration Date: April 14, 2010 Nabil Bitar, Verizon +Expiration Date: November 3, 2010 Nabil Bitar, Verizon Attila Takacs, Ericsson - October 14, 2009 + May 3, 2010 Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet PBB-TE - draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt + draft-ietf-ccamp-gmpls-ethernet-pbb-te-04.txt Status of this Memo - This Internet-Draft is submitted to IETF in full conformance with the - provisions of BCP 78 and BCP 79. This document may contain material - from IETF Documents or IETF Contributions published or made publicly - available before November 10, 2008. The person(s) controlling the - copyright in some of this material may not have granted the IETF - Trust the right to allow modifications of such material outside the - IETF Standards Process. Without obtaining an adequate license from - the person(s) controlling the copyright in such materials, this - document may not be modified outside the IETF Standards Process, and - derivative works of it may not be created outside the IETF Standards - Process, except to format it for publication as an RFC or to - translate it into languages other than English. + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. 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 - This Internet-Draft will expire on April 14, 2010. + This Internet-Draft will expire on November 3, 2010. Copyright and License Notice - Copyright (c) 2009 IETF Trust and the persons identified as the + Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal - Provisions Relating to IETF Documents in effect on the date of - publication of this document (http://trustee.ietf.org/license-info). - Please review these documents carefully, as they describe your rights - and restrictions with respect to this document. + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. Abstract This specification is complementary to the GMPLS Ethernet Label - Switching Architecture and Framework [ARCH] and describes the + Switching Architecture and Framework [RFC5828] and describes the technology specific aspects of GMPLS control for Provider Backbone Bridge Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary GMPLS extensions and mechanisms are described to establish Ethernet PBB-TE point to point (P2P) and point to multipoint (P2MP) connections. This document supports, but does not modify, the standard IEEE data plane. Table of Contents 1 Introduction ........................................... 4 @@ -98,35 +104,37 @@ 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 [RFC2119]. 1. Introduction The IEEE 802.1 Provider Backbone Bridge Traffic Engineering (PBB-TE) [IEEE 802.1Qay] standard supports the establishment of explicitly routed traffic engineered paths within Provider Backbone Bridged - (PBB) networks. PBB-TE allows disabling: the Spanning Tree Protocol, - unknown destination address forwarding and source address learning + (PBB) networks. PBB-TE allows disabling of: + - the Spanning Tree Protocol + - unknown destination address forwarding + - source address learning for administratively selected VLAN Identifiers. With PBB-TE an external provisioning system or control plane can be used to configure static entries in the managed objects of bridges and so establish traffic engineered paths in the network. Generalized MPLS (GMPLS) [RFC3945] is a family of control plane protocols designed to operate in connection oriented and traffic engineering transport networks. GMPLS is applicable to a range of network technologies including Layer 2 Switching capable networks (L2SC). The purpose of this document is to specify extensions for a GMPLS based control plane to manage PBB-TE explicitly routed traffic engineered paths. This specification is complementary to with the - GMPLS Ethernet Label Switching Architecture and Framework [ARCH] + GMPLS Ethernet Label Switching Architecture and Framework [RFC5828] document. 1.1. Co-authors This document is the result of a large team of authors and contributors. The following is a list of the co-authors: Don Fedyk (Alcatel-Lucent) David Allan (Ericsson) Himanshu Shah (Force10 Networks) @@ -344,27 +352,27 @@ from an intersecting switch or link except they share a single forwarding entry. The forwarding memory savings from shared forwarding can be quite dramatic in some topologies where a high degree of meshing is required however it is typically easier to achieve when the connectivity is known in advance. Normally the originating GMPLS switch will not have knowledge of the set of shared forwarding paths rooted on the source or destination switch. - Use of a Path Computation Server [PATHCOMP] or other planning style - of tool with more complete knowledge of the network configuration is - a way to impose pre-selection of shared forwarding with multiple - paths using a single forwarding entry and optimizing for both - directions. In this scenario the originating switch uses the - LABEL_SET and UPSTREAM_LABEL objects to indicate selection of the - shared forwarding labels at both ends. + Use of a Path Computation Server [RFC4655] or other planning style of + tool with more complete knowledge of the network configuration is a + way to impose pre-selection of shared forwarding with multiple paths + using a single forwarding entry and optimizing for both directions. + In this scenario the originating switch uses the LABEL_SET and + UPSTREAM_LABEL objects to indicate selection of the shared forwarding + labels at both ends. 3.2. P2P connections procedures for shared forwarding The ESP-VID/ESP-MAC DA can be considered to be a shared forwarding identifier or label consisting of some number of P2P connections distinctly identified by the MAC ESP-VID/ESP-MAC DA/ESP- MAC SA tuple. This is analogous to an LDP label merge but in the shared forwarding case the original ESP header still identifies the complete path. Resources can continue to be allocated per LSP with Shared forwarding. @@ -413,21 +421,21 @@ 3) SHOULD set the GPID to Ethernet (33) [RFC3471]. 4) MUST set the UPSTREAM_LABEL to the ESP-VID1/ESP-MAC1 tuple where the ESP-VID1 is administered locally for the local MAC address: MAC1 5) SHOULD set the LABEL_SET or SUGGESTED_LABEL if it chooses to influence the choice of ESP-VID/ESP-MAC DA. - 6) SHOULD look at Call / Connection ID for Carrying I-SID. + 6) MAY carry an I-SID via Call / Connection ID [RFC4974]. Intermediate and egress switch processing is not modified by this document, i.e., is per [RFC3473]. However, as previously stated intermediate bridges supporting the 802_1 PBB-TE switching type MUST NOT modify LABEL values. The ESP-VID1/ESP-MAC1 tuple contained in the UPSTREAM_LABEL are used to create a static forwarding entry in the Filtering Database of bridges at each hop for the upstream direction. This behavior is inferred from the switching type which is 802_1 PBB-TE. The port @@ -502,31 +510,32 @@ 4.5. Service Instance Identification The I-SID is used to uniquely identify services within the network. Unambiguous identification is achieved by ensuring global uniqueness of the I-SIDs within the network or at least between any pair of edge switches. On IB-BEBs the Backbone Service Instance Table is used to configure the mapping between I-SIDs and ESPs. This configuration can be either manual or semi-automated by signaling described here. - RSVP-TE signaling MAY be used to automate I-SID to ESP mapping. By + RSVP-TE Signaling MAY be used to automate I-SID to ESP mapping. By relying on signaling it is ensured that the same I-SID is assigned to the service and mapped to the same ESP. Note, by signaling the I-SID associated to the ESP one can ensure that IB-BEBs select the appropriate CBP port. - The CALL signaling [RFC4974] can be used to create the I-SID + The CALL signaling [RFC4974] MAY be used to create the I-SID association between the endpoints prior to Eth-LSP establishment. - Alternatively, the PATH messages can carry the I-SID association at - the time of Eth-LSP signaling. Therefore it is possible to create I- - SID association either when the path is set up or at a later time. + Alternatively, the GMPLS RSVP-TE PATH messages can carry the I-SID + association at the time of Eth-LSP signaling. Therefore it is + possible to create I-SID association either when the path is set up + or at a later time. A new Service ID TLV is defined for the CALL_ATTRIBUTES and LSP_ATTRIBUTES objects. The format is depicted below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBA) | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags | @@ -612,24 +621,24 @@ the mismatch MUST immediately generate an error: Routing problem (24) / Unacceptable label value (6). Handling of this error is according to [RFC3209]. 6. Security Considerations This document does not introduces new security issues; the considerations in [RFC4872] and [RFC4873] apply. The GMPLS controlled Ethernet subnet consists of trusted devices and - that the UNI ports or in this case BEB Ethernet UNI Ports to the - domain are untrusted. Care is required to ensure untrusted access to - the trusted domain does not occur. Where GMPLS is applied to the - control of VLAN only, the commonly known techniques for mitigation of + that UNI ports or in this case BEB Ethernet UNI Ports to the domain + are untrusted. Care is required to ensure untrusted access to the + trusted domain does not occur. Where GMPLS is applied to the control + of VLAN only, the commonly known techniques for mitigation of Ethernet DOS attacks may be required on UNI ports. PBB-TE has been designed to interwork with legacy VLANs and the VLANs provide isolation from Ethernet legacy control planes. 7. IANA Considerations - Assign a new Switching Type: "802_1 PBB-TE" (suggested value 40) in the GMPLS Signaling Parameters / Switching Types registry. - Assign a new globally defined error value: "PBB-TE Ethernet Label @@ -646,23 +655,20 @@ is carried in the CALL_ATTRIBUTES Object (class = 201, C-Type = 1) [MLN-EXT]. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [ARCH] Fedyk, D. Berger, L., Andersson L., "GMPLS Ethernet Label - Switching Architecture and Framework", work in progress. - [RFC3471] Berger, L. et.al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description" IETF RFC 3471, January 2003. [RFC3473] Berger, L. et.al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", IETF RFC 3473, January 2003. [RFC3945] Mannie, E. et.al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", IETF RFC 3945, October 2004. @@ -670,37 +676,39 @@ [MLN-EXT] Papadimitriou, D. et al, "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", work in progress. [RFC5420] Farrel, A. Ed., "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE), IETF RFC 5420, February 2009. 8.2. Informative References + [RFC5828] Fedyk, D. Berger, L., Andersson L., "GMPLS Ethernet Label + Switching Architecture and Framework", work in progress. [IEEE 802.1ay] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment : Provider Backbone Bridges Traffic Engineering (2009). [IEEE 802.1ag] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management (2007). [IEEE 802.1ah] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment 6: Provider Backbone Bridges", (2008) [RFC4875] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to Multipoint TE LSPs", IETF RFC 4875, May 2007 - [PATHCOMP] Farrel, A. et.al., "Path Computation Element (PCE) + [RFC4655] Farrel, A. et.al., "Path Computation Element (PCE) Architecture", IETF RFC 4655, August 2006 [RFC4872] Lang, J. et.al., "RSVP-TE Extensions in support of End-to- End Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery ", RFC 4872, May 2007. [RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May 2007. @@ -767,11 +775,11 @@ COO RTP IE Fixed 3 Hanagar St. Neve Ne'eman B, 45241 Hod Hasharon, Israel Email: nurit.sprecher@nsn.com Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 Email: lberger@labn.net -Generated on: Wed Oct 14 13:52:17 EDT 2009 +Generated on: Mon May 3 10:05:11 EDT 2010