--- 1/draft-ietf-ccamp-gmpls-ethernet-pbb-te-05.txt 2010-09-29 01:12:21.000000000 +0200 +++ 2/draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt 2010-09-29 01:12:21.000000000 +0200 @@ -1,21 +1,21 @@ Internet Draft Don Fedyk, Alcatel-Lucent Category: Standards Track Himanshu Shah, Force10 Networks -Expiration Date: February 18, 2011 Nabil Bitar, Verizon +Expiration Date: March 28, 2011 Nabil Bitar, Verizon Attila Takacs, Ericsson - August 18, 2010 + September 28, 2010 Generalized Multiprotocol Label Switching (GMPLS) control of - Ethernet PBB-TE + Ethernet Provider Backbone Traffic Engineering (PBB-TE) - draft-ietf-ccamp-gmpls-ethernet-pbb-te-05.txt + draft-ietf-ccamp-gmpls-ethernet-pbb-te-06.txt Status of this Memo 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 @@ -36,21 +36,21 @@ 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 February 18, 2011. + This Internet-Draft will expire on March 28, 2011. Copyright and License Notice 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -72,39 +72,39 @@ Table of Contents 1 Introduction ........................................... 4 1.1 Co-authors ............................................. 4 2 Terminology ............................................ 5 2.1 PBB-TE and GMPLS Terminology ........................... 5 3 Creation and Maintenance of PBB-TE paths using GMPLS ... 6 3.1 Shared Forwarding ...................................... 9 3.2 P2P Connections Procedures for Shared Forwarding ....... 10 - 4 Specific Procedures .................................... 10 - 4.1 P2P Ethernet LSPs ..................................... 10 - 4.1.1 P2P Path Maintenance ................................... 11 + 4 Specific Procedures .................................... 11 + 4.1 P2P Ethernet LSPs ..................................... 11 + 4.1.1 P2P Path Maintenance ................................... 12 4.2 P2MP Ethernet-LSPs ..................................... 12 - 4.3 PBB-TE Ethernet Label .................................. 12 + 4.3 PBB-TE Ethernet Label .................................. 13 4.4 Protection Paths ....................................... 13 4.5 Service Instance Identification ....................... 13 5 Error conditions ....................................... 15 5.1 ESP-VID related errors ............................... 15 - 5.1.1 Invalid ESP-VID value in the PBB-TE Ethernet Label .... 15 - 5.1.2 Allocated ESP-VID range is exhausted .................. 15 + 5.1.1 Invalid ESP-VID value in the PBB-TE Ethernet Label .... 16 + 5.1.2 Allocated ESP-VID range is exhausted .................. 16 5.2 Invalid MAC Address .................................... 16 - 6 Security Considerations ................................ 16 + 6 Security Considerations ................................ 17 7 IANA Considerations .................................... 17 - 8 References ............................................. 17 - 8.1 Normative References ................................... 17 - 8.2 Informative References ................................. 18 + 8 References ............................................. 18 + 8.1 Normative References ................................... 18 + 8.2 Informative References ................................. 19 9 Acknowledgments ........................................ 19 - 10 Author's Address ....................................... 19 + 10 Author's Address ....................................... 20 Conventions used in this document 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) @@ -160,31 +160,33 @@ - C-MAC Customer MAC - C-VID Customer VLAN ID - C-VLAN Customer VLAN - ESP Ethernet Switched Path - ESP-MAC SA ESP Source MAC Address - ESP-MAC DA ESP Destination MAC Address - ESP-VID ESP VLAN ID - Eth-LSP Ethernet Label Switched Path - IB-BEB A BEB comprising of both I and B components - I-SID Ethernet Service Instance Identifier + - TAG An Ethernet Header Field with Type and Values - MAC Media Access Control - PBB Provider Backbone Bridges - PBB-TE Provider Backbone Bridges Traffic Engineering - PIP Provider Instance Port - PNP Provider Network Port - PS Protection Switching - P2P Point to Point - P2MP Point to Multipoint - SVL Shared VLAN Learning - - TESI TE Service Instance + - TESI Traffic Engineering Service Instance - VID VLAN ID + - VIP Virtual Instance Port - VLAN Virtual LAN 2.1. PBB-TE and GMPLS Terminology The PBB-TE specification [IEEE 802.1Qay] defines some additional terminology to clarify the PBB-TE functions. We repeat these here in expanded context to translate from IEEE to GMPLS terminology. The terms bridge and switch are used interchangeably in this document. The signaling extensions described here apply equally well to a PBB- TE capable bridge supporting GMPLS signaling or to a GMPLS capable @@ -228,21 +230,35 @@ IEEE PBB-TE is a connection oriented Ethernet technology. PBB-TE ESPs are created bridge by bridge (or switch by switch) by simple configuration of Ethernet forwarding entries. This document describes the use of GMPLS as a valid control plane for the set-up, teardown, protection and recovery of ESPs and TESIs and specifies the required RSVP-TE extensions for the control of PBB-TE service instances. PBB-TE ESP and services are always originated and terminated on IB- Backbone Edge Bridges (IB-BEBs). IB-BEBs are constituted of I and B - components, this is illustrated in Figure 1. + components, this is illustrated in Figure 1. A B-component refers to + the structure and mechanisms that support the relaying of frames + identified by Backbone VLANs in a Provider Backbone Bridge. An I- + component refers to the structure and mechanisms that support the + relaying of frames identified by service instances (I-SIDs) in a + Provider Backbone Bridge. PBB and PBB-TE relay frames with added I- + Component TAGs in the I-Component and VLAN TAGs in the B-Component. + PBB and PBB-TE forward frames based on VLAN ID in the VLAN TAG (in + the PBB case a B-VID) until the destination MAC address is supported + locally by a B-Component on this bridge indicating the destination + has been reached. At that point, the B-VLAN tag is removed and + processing or forwarding on the next TAG begins (in the PBB case an + I-Component TAG) until the I-Component identified by the I-SID is + reached. At the I-component the I-Component TAG is removed and the + next Ethernet type identifies the TAG etc. An Ethernet service supported by a PBB-TE TESI is always attached to a Customer Network Port (CNP) of the I-component. A Service Instance Identifier (I-SID) is assigned for the service. I-SIDs are only looked at by source and destination (edge) bridges so I-SIDs are transparent to path operations and MAY be signaled. The I and B components have internal ports which are connected via an internal LAN. These internal ports are the Provider Instance Ports (PIPs) and Customer Backbone Ports (CBPs). PIPs and CBPs are not visible outside the IB-BEB. ESPs are always originated and terminated on CBP ports @@ -411,22 +427,22 @@ the following we discuss the establishment of bidirectional Eth-LSPs. Note however that it is also possible to use RSVP-TE to configure unidirectional ESPs, if the UPSTREAM_LABEL is not included in the PATH message. To initiate a bidirectional Eth-LSP, the initiator of the PATH message MUST use the procedures outlined in [RFC3473] with the following specifics: 1) MUST set the LSP encoding type to Ethernet (2) [RFC3471]. - 2) MUST set the LSP switching type to 802_1 PBB-TE suggested value 40 - IANA to define, assigned by this document]. + 2) MUST set the LSP switching type to "802_1 PBB-TE" suggested value + 40. 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. @@ -636,27 +653,27 @@ the PBB-TE Ethernet Label. Depending on the size of the allocated VLAN range and the number of Eth-LSPs terminated on a particular bridge, it is possible that the available VIDs are exhausted and hence no PBB-TE Ethernet Label can be allocated. In this case the destination bridge SHOULD generate a PathErr message with error code: Routing problem (24) and error value: MPLS Label allocation failure (9). 5.2. Invalid MAC Address - IEEE defines a set of reserved MAC addresses that have special - meaning, processing and follow specific forwarding rules. These - addresses cannot be used for PBB-TE ESPs. In the case the PBB-TE - Ethernet Label refers to such a MAC address, a bridge encountering - the mismatch MUST immediately generate an error: Routing problem (24) - / Unacceptable label value (6). Handling of this error is according - to [RFC3209]. + IEEE defines a set of reserved MAC addresses Table 8-1 [IEEE 802.1Q] + that have special meaning, processing and follow specific forwarding + rules. These addresses cannot be used for PBB-TE ESPs. In the case + the PBB-TE Ethernet Label refers to such a MAC address, a bridge + encountering 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. GMPLS controlled Ethernet PBB-TE system assumes that users and devices attached to UNIs may behave maliciously, negligently, or incorrectly. Intra-provider control traffic is trusted to not be malicious. In general, these requirements are no different from the @@ -693,84 +710,87 @@ VID allocation failure" (suggested value: 35?) under the "Routing problem" (24) error code in the RSVP Parameters / Error Codes and Globally-Defined Error Value Sub-Codes registry. - Assign a new type from the Attributes TLV Space in the RSVP-TE Parameters registry (suggested value 2) for the Service ID TLV that is carried in the LSP_ATTRIBUTES Object (class = 197, C-Type = 1) [RFC5420]. - Assign a new type (suggested value 2) for the Service ID TLV that - is carried in the CALL_ATTRIBUTES Object (class = 201, C-Type = - 1) [MLN-EXT]. + is carried in the CALL_ATTRIBUTES Object (class = 202, C-Type = + 1) Registry class defined by [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. [RFC3471] Berger, L. et.al., "Generalized Multi-Protocol Label - Switching (GMPLS) Signaling Functional Description" IETF RFC 3471, - January 2003. + 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. [MLN-EXT] Papadimitriou, D. et al, "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", draft-ietf-ccamp-gmpls-mln-extensions, 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. + [RFC4872] Lang, J. et.al., "RSVP-TE Extensions in support of + End-to-End Generalized Multi-Protocol Label Switching + (GMPLS)-based Recovery", RFC 4871, May 2007. + + [RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May + 2007. + + [RFC3209] Awduche, D. et.al., "RSVP-TE: Extensions to RSVP for LSP + Tunnels, IETF RFC 3209, December 2001. + + [RFC4974] Papadimitriou, D. and Farrel, A. "Generalized MPLS (GMPLS) + RSVP-TE Signaling Extensions in Support of Calls", August 2007. + 8.2. Informative References [RFC5828] Fedyk, D. Berger, L., Andersson L., "GMPLS Ethernet Label Switching Architecture and Framework", RFC 5828, March 2010. [IEEE 802.1Qay] "IEEE Standard for Local and Metropolitan Area Networks - Virtual Bridged Local Area Networks - Amendment : Provider Backbone Bridges Traffic Engineering (2009). + [IEEE 802.1Q] "IEEE Standard for Local and Metropolitan Area + Networks - Virtual Bridged Local Area Networks", + IEEE Std 802.1Q-2005, May 19, 2006. + [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 [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. - - [RFC3209] Awduche, D. et.al., "RSVP-TE: Extensions to RSVP for LSP - Tunnels, IETF RFC 3209, December 2001. - - [RFC4974] Papadimitriou, D. and Farrel, A. "Generalized MPLS (GMPLS) - RSVP-TE Signaling Extensions in Support of Calls", August 2007. - [RFC5920] Fang, L. et.al.,"Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [MACSEC] "IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security IEEE 802.1AE-2006", August 18, 2006. 9. Acknowledgments The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen @@ -826,11 +846,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 Aug 18 15:53:56 EDT 2010 +Generated on: Tue Sep 28 17:33:45 EDT 2010