Internet Draft Don Fedyk, Nortel Category: Standards Track Himanshu Shah, Ciena Expiration Date: August 25, 2009 Nabil Bitar, Verizon Attila Takacs, Ericsson February 25, 2009 Generalized Multiprotocol Label Switching (GMPLS) control of Ethernet PBB-TE draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.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 memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 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 BCP 78 and 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/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 August 25, 2009. Fedyk, et. al. Standards Track [Page 1] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 Copyright and License Notice Copyright (c) 2009 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 carefully, as they describe your rights and restrictions with respect to this document. Abstract This specification is complementary to the GMPLS controlled Ethernet architecture document [ARCH] 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. Fedyk, et. al. Standards Track [Page 2] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 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 4 Specific Procedures ....................................... 9 4.1 P2P Ethernet LSPs ........................................ 9 4.1.1 Shared Forwarding ......................................... 10 4.1.2 P2P connections procedures for shared forwarding .......... 11 4.1.3 P2P Path Maintenance ...................................... 11 4.2 P2MP Ethernet-LSPs ........................................ 12 4.2.1 Maintenance Procedures .................................... 12 4.3 PBB-TE Ethernet Label ..................................... 12 4.4 Protection Paths .......................................... 13 4.5 Service Instance Identification .......................... 13 5 Error conditions .......................................... 15 5.1 Invalid ESP-VID value for PBB-TE ......................... 15 5.2 Invalid MAC Address ....................................... 15 5.3 Switch is not ESP P2MP capable ............................ 15 6 Security Considerations ................................... 15 7 IANA Considerations ....................................... 16 7.1 Error Codes ............................................... 16 8 References ................................................ 16 8.1 Normative References ...................................... 16 8.2 Informative References .................................... 16 9 Acknowledgments ........................................... 17 10 Author's Address .......................................... 17 Fedyk, et. al. Standards Track [Page 3] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 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) [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 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 draft is complementary to with the GMPLS Ethernet Label Switching Architecture and Framework [ARCH]. 1.1. Co-authors This document is the result the a large team of authors and contributors. The following is a list of the co-authors: Don Fedyk (Nortel) David Allan (Nortel) Himanshu Shah (Ciena) Nabil Bitar (Verizon) Attila Takacs (Ericsson) Diego Caviglia (Ericsson) Alan McGuire (BT) Nurit Sprecher (Nokia Siemens Networks) Lou Berger (LabN) Fedyk, et. al. Standards Track [Page 4] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 2. Terminology In addition to well understood GMPLS terms, this memo uses terminology from IEEE 802.1 [IEEE 802.1Qah] [IEEE 802.1Qay]: - BCB Backbone Core Bridge - BEB Backbone Edge Bridge - B-MAC Backbone MAC - B-VID Backbone VLAN ID - B-VLAN Backbone VLAN - CBP Customer Backbone Port - CCM Continuity Check Message - CNP Customer Network Port - C-MAC Customer MAC - C-VID Customer VLAN ID - C-VLAN Customer VLAN - DMAC Destination MAC Address - 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 - MAC Media Access Control - MMAC Multicast or Group MAC address - PBB Provider Backbone Bridges - PBB-TE Provider Backbone Bridges Traffic Engineering - PIP Provider Instance Port - PNP Provider Network Port - P2P Point to Point - P2MP Point to Multipoint - SVL Shared VLAN Learning - TESI TE Service Instance - VID VLAN ID - 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. - Ethernet Switched Path (ESP): A provisioned traffic engineered unidirectional connectivity path between two or more Customer Backbone Ports (CBPs) which extends over a Provider Backbone Bridge Network (PBBN). The path is Fedyk, et. al. Standards Track [Page 5] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 identified by the 3-tuple . An ESP is point-to-point (P2P) or point-to-multipoint (P2MP). An ESP is analogous to a (unidirectional) point-to-point or point-to- multipoint LSP. We use the term Ethernet-LSP (Eth-LSP) for GMPLS established ESPs. - Point-to-point ESP: An ESP between two CBPs. The ESP-DA and the ESP-SA in the ESP's 3- tuple identifier are the individual MAC addresses of the two CBPs. - Point-to-multipoint ESP: An ESP among one root CBP and n leaf CBPs. The ESP-DA in the ESP's 3-tuple identifier is a group MAC address identifying the n leaf CBPs, and the ESP-SA is the individual MAC address of the root. - Point-to-Point PBB-TE service instance (P2P TESI): A service instance supported by two point-to-point ESPs where the ESPs' endpoints have the same CBP MAC addresses. The two unidirectional ESP are forming a bidirectional service. The PBB- TE standard [IEEE 802.1Qay] notes the following: for reasons relating to TE service monitoring diagnostics, operational simplicity, etc. the IEEE PBB-TE standard assumes that the point- to-point ESPs associated with a point-to-point TESI are co- routed. Support for a point-to-point TE services which comprises non co-routed ESPs is problematic, and is not defined in this standard. Hence, a GMPLS bidirectional LSP is analogous to a P2P TE Service instance. We use the term bidirectional Ethernet-LSP (Eth-LSP) for GMPLS established P2P PBB-TE Service instances. 3. Creation and Maintenance of PBB-TE paths using GMPLS IEEE PBB-TE is a connection oriented Ethernet technology. PBB-TE ESPs are created 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. 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. The I and B Fedyk, et. al. Standards Track [Page 6] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 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 and use the MAC address of that port. The I-Component encapsulates the service frames arriving from the CNP by adding an I-SID and a complete Ethernet MAC header with an ESP-MAC DA and ESP-MAC SA. The B-Component adds the ESP-VID. GMPLS is being defined here to establish ESPs and TESIs. As it can be seen from the above this requires configuration of both the I and B components of the IB-BEBs connected by the ESPs. In the GMPLS control plane TE Router IDs are used to identify the IB- BEBs and Backbone Core Bridges (BCBs), and TE Links that describes links connected to PNPs and CNPs. TE Links are not associated with CBPs or PIPs. Note that since multiple internal CBPs may exit an IB-BEB receiving a PATH message must be able to determine the appropriate CBP that is the termination point of the ESP. To this end, IB-BEBs SHOULD advertises the CNP TE Links in the GMPLS control plane and RSVP-TE signaling SHOULD use the CNP TE Links to identify the termination point of Eth-LSPs. An IB-BEB receiving a PATH message specifying one of its CNPs can locally determine which CBPs have internal connectivity to the I-component supporting the given CNP. In the case there are more than one suitable CBPs, and no I-SID information is provided in the PATH message or previously in the associated Call setup, then the IB-BEB can decide freely which CBP to assign to the requested connection. On the other hand, if there is information on the service (I-SID) that the given ESP will support, then the IB-BEB MUST first determine which PIP and CBP is configured with the I-SID and MUST assign that CBP to the ESP. Fedyk, et. al. Standards Track [Page 7] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 Backbone Edge Bridge (BEB) +------------------------------------------------------+ | | | | | I-Component Relay B-Component Relay | | +-----------------------+ +---------------------+ | | | +---+ | | B-VID | | | | |VIP| | | +---+ +---+ | | | | +---+ | +---|CBP| |PNP|------ | | | | | +---+ +---+ | | | | +---+ +---+ | | | | | ------|CNP| |PIP|----+ | | | | | +---+ +---+ | | | | | +-----------------------+ +---------------------+ | | | | PBB Edge Bridge | +------------------------------------------------------+ ^--------Configured--------------^ ^-----------GMPLS or Configured------^ Figure 1 IB-BEBs and GMPLS identifiers Control TE Router ID TE Router ID Plane | (TE Link) | V | V +----+ | +-----+ Data | | | label=ESP:VID/MAC DA | | Plane | | V label=ESP:VID/MMAC | | -----N N----------------------------N N---------- | | PBB-TE | | \ Network | | / | Or +----+ /+-----+ Customer BCB ESP:MAC IB-BEB Facing Ethernet Ports Figure 2 Ethernet/GMPLS Addressing & Label Space PBB-TE defines the tuple of as a unique connection identifier in the data plane but the forwarding operation only uses the ESP-MAC DA and the ESP-VID in each direction. The ESP-VID typically comes from a small number of VIDs dedicated to PBB-TE. ESP-VIDs can be reused across ESPs. There is no requirement that ESP-VIDs for two ESPs that form a P2P TESI be the same. Fedyk, et. al. Standards Track [Page 8] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 When configuring a ESP with GMPLS, the ESP-MAC DA and ESP-VID are carried in a generalized label object and are assigned hop by hop but are invariant within a domain. This invariance is similar to GMPLS operation in transparent optical networks. As is typical with other technologies controlled by GMPLS, the data plane receiver must accept, and usually assigns, labels from its available label pool. This, together with the label invariance requirement mentioned above, result in each PBB-TE Ethernet Label being a domain wide unique label, with a unique ESP-VID + ESP-MAC DA, for each direction. The following illustrates PBB-TE Ethernet Labels and ESPs for a P2P TESI. GMPLS Upstream Label (60 bits) GMPLS Downstream Label (60 bits) Upstream PBB-TE ESP 3-tuple (108 bits) Downstream PBB-TE ESP 3-tuple (108 bits) Table 1 Labels and ESPs 4. Specific Procedures 4.1. P2P Ethernet LSPs Note, PBB-TE is designed to be bidirectional and symmetrically routed just like Ethernet. That is, complete and proper functionality of Ethernet protocols is only guaranteed for bidirectional Eth-LSPs. To initiate a bidirectional Eth-LSP, the initiator of the PATH message uses procedures outlined in [RFC3473], it: 1) Sets the LSP encoding type to Ethernet. 2) Sets the LSP switching type to 802_1 PBB-TE suggested value 40 [IANA to define]. 3) Sets the GPID to service type. 4) Sets the UPSTREAM_LABEL to the ESP-VID1/ESP-MAC1 tuple where the ESP-VID1 is administered locally for the local MAC address: MAC1 5) Optionally sets the LABEL_SET or SUGGESTED_LABEL if it chooses to influence the choice of ESP-VID/ESP-MAC DA. 6) Optionally look at Call / Connection ID for Carrying I-SID. Intermediate and egress switch processing is not modified by this Fedyk, et. al. Standards Track [Page 9] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 document, i.e., is per [RFC3473]. Note, 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 is 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 derived from the RSVP_HOP object and the ESP-VID1 and ESP- MAC1 included in the PBB-TE Ethernet Label constitute the static entry. At the destination, an ESP-VID2 is allocated for the local MAC address: MAC2, the ESP-VID2/ESP-MAC2 tuple is passed in the LABEL object in the RESV message. As with the PATH message, intermediate switch processing is per [RFC3473], and the LABEL object is passed on unchanged, upstream. The ESP-VID2/ESP-MAC2 tuple contained in the LABEL Object is installed in the forwarding table as a static forwarding entry at each hop. This creates a bidirectional path as the PATH and RESV messages follow the same path. 4.1.1. Shared Forwarding One capability of a connectionless Ethernet data plane is to reuse destination forwarding entries for packets from any source within a VLAN to a destination. When setting up P2P PBB-TE connections for multiple sources sharing a common destination this capability MAY be preserved provided certain requirements are met. We refer to this capability as Shared Forwarding. Shared forwarding is invoked based on policy when conditions are met. It is a local decision by label allocation at each end plus the path constraints. Shared forwarding has no impact on the actual paths setup, but it allows the reduction of forwarding entries. Shared forwarding paths are identical in function to independently routed paths that share a path from an intersecting switch or link except they share a single forwarding entry. Share forwarding savings 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 know 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 multiplexes to use for both directions. In this scenario the originating switch uses the LABEL_SET and UPSTREAM_LABEL objects to indicate selection of the Fedyk, et. al. Standards Track [Page 10] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 shared forwarding multiplexes at both ends. 4.1.2. P2P connections procedures for shared forwarding The ESP-VID/ESP-MAC DA MAY be considered to be a shared forwarding identifier or label for a multiplex 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. VLAN tagged Ethernet packets include priority marking. Priority bits MAY be used to indicate class of Service (COS) and drop priority. Thus, traffic from multiple COSs could be multiplexed on the same Eth-LSP (i.e., similar to E-LSPs) and queuing and drop decisions are made based on the p-bits. This means that the queue selection can be done based on a per flow (i.e., Eth-LSP + priority) basis and is decoupled from the actual steering of the packet at any given switch. A switch terminating an Eth-LSP will frequently have more than one suitable candidate for sharing a forwarding entry (common ESP- VID/ESP-MAC DA, unique ESP-MAC SA). It is a local decision of how this is performed but the best choice is a path that maximizes the shared forwarding. The concept of bandwidth management still applies equally well with shared forwarding. As an example consider a PBB-TE edge switch that terminates an Ethernet LSP with the following attributes: bandwidth B1, ESP-MAC DA D, ESP-MAC SA S1, ESP-VID V. A request to establish an additional Ethernet LSP with attributes (bandwidth B2, ESP-MAC DA D, ESP-MAC SA S2, ESP-VID V) can be accepted provided there is sufficient link capacity remaining. 4.1.3. P2P Path Maintenance Make before break procedures can be employed to modify the characteristics of a P2P Eth LSP. As described in [RFC3209], the LSP ID in the sender template is updated as the new path is signaled. The procedures (including those for shared forwarding) are identical to those employed in establishing a new LSP, with the extended tunnel ID in the signaling exchange ensuring that double booking of the associated resources does not occur. Where individual paths in a protection group are modified, signaling procedures may be combined with Protection Switching (PS) Fedyk, et. al. Standards Track [Page 11] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 coordination to administratively force PS switching operations such that modifications are only ever performed on the protection path. 4.2. P2MP Ethernet-LSPs PBB-TE supports P2MP VID/Multicast MAC (MMAC) forwarding. In P2MP the whole tree in the forward direction has the same destination MMAC ESP-MAC-DA. The procedures outlined in [RFC3473] and [RFC4875]could be adapted to signal P2MP LSPs for the source (point) to destination (multipoint) direction. Each one of the branches of the P2MP Eth-LSP would be associated with a reverse path symmetric and congruent P2P Eth-LSP. Complete procedures for signaling bidirectional P2MP are out of scope for this document. 4.2.1. Maintenance Procedures Maintenance and modification to a P2MP tree can be achieved by a number of means. The preferred technique is to modify existing VLAN configuration vs. assignment of a new label and completely constructing a new tree. Make before break on a live tree reusing existing label assignments requires a 1:1 or 1+1 construct. The protection switch state of the traffic is forced on the working tree and locked (PS not allowed) while the backup tree is modified. Explicit path tear of leaves to be modified is required to ensure no loops are left behind as artifacts of tree modification. Once modifications are complete, a forced switch to the backup tree occurs and the original tree may be similarly modified. This also suggests that 1+1 or 1:1 resilience can be achieved for P2MP trees for any single failure (switch on any failure and use restoration techniques to repair the failed tree). 4.3. PBB-TE Ethernet Label The PBB-TE Ethernet Label is a new generalized label with the following format: Fedyk, et. al. Standards Track [Page 12] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0| ESP VID | ESP MAC (highest 2 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ESP MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 PBB-TE Ethernet Label This format is used to carry for both P2P and P2MP Eth-LSPs. For P2P Eth-LSPs labels the fields specify a VID and a unicast MAC address, while for P2MP Eth-LSPs a VID and a group MAC address is carried in the label. The PBB-TE Ethernet Label is a domain wide unique label and MUST be passed unchanged at each hop. This has similarity to the way in which a wavelength label is handled at an intermediate switch that cannot perform wavelength conversion, and is described in [RFC3473]. 4.4. Protection Paths When protection is used for path recovery it is required to associate the working and protection paths into a protection group. This is achieved as defined in [RFC4872] and [RFC4873] using the ASSOCIATION and PROTECTION objects. 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 can 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 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- Fedyk, et. al. Standards Track [Page 13] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 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 object. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I-SID Set 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I-SID Set n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Service ID TLV - Flags: are used to control properties of service configuration. This document does not define flags. - I-SID Set TLV: is used to define a list or range of I-SIDs. Multiple I-SID Set TLVs can be present. At least one I-SID Set TLV MUST be present. In most of the cases a single I-SID Set with a single I-SID value is used. The I-SID Set TLV is used to define a list or range of I-SIDs. The format of the I-SID Set TLV is based on the LABEL_SET Object: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | I-SID 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | I-SID n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 I-SID Set TLV - Action: 8 bits The following actions are defined: list (0), range (1). Fedyk, et. al. Standards Track [Page 14] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 - I-SID: 24 bits The I-SID value identifies a particular backbone service instance. 5. Error conditions The following errors are possible. They are extension of some base error types that arise due to the constraints on the label. 5.1. Invalid ESP-VID value for PBB-TE The originator of the error is not configured to use the ESP-VID value for PBB-TE in conjunction with GMPLS signaling of tuples. This may be originated by any switch along the path. Note this is a refinement of the more general Unacceptable label value Error code. 5.2. Invalid MAC Address The MAC address is out of a reserved range that cannot be used by the switch which is processing the address. While almost all MAC addresses are valid there are a small number of IEEE reserved MAC addresses. Note this is a refinement of the more general Unacceptable label value Error code. 5.3. Switch is not ESP P2MP capable This error may arise only in P2MP Tree allocation. 6. Security Considerations The architecture assumes that 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 Ethernet DOS attacks may be required on UNI ports. Fedyk, et. al. Standards Track [Page 15] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 7. IANA Considerations New values are required for signaling and error codes as indicated IANA to define. Value are needed for: - Switching type: 802_1 PBB-TE suggested value 40. 7.1. Error Codes - Invalid ESP-VID value for PBB-TE - Invalid MAC Address - Switch is not ESP P2MP capable 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. [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. 8.2. Informative References [IEEE 802.1Qay] "IEEE standard for Provider Backbone Bridges Traffic Engineering", work in progress. [IEEE 802.1ag] "IEEE Standard for 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) Fedyk, et. al. Standards Track [Page 16] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 [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) Architecture", work in progress. [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. [Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM Functions and Mechanisms for Ethernet based Networks ", (2006). 9. Acknowledgments The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen Shew, Dave Martin and Sandra Ballarte for their contributions to this document. 10. Author's Address Don Fedyk Nortel Networks 600 Technology Park Drive Billerica, MA, 01821 Email: dwfedyk@nortel.com David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA Email: dallan@nortel.com Fedyk, et. al. Standards Track [Page 17] Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-02.txt February 25, 2009 Himanshu Shah Ciena 35 Nagog Park, Acton, MA 01720 Email: hshah@ciena.com Nabil Bitar Verizon, 40 Sylvan Rd., Waltham, MA 02451 Email: nabil.n.bitar@verizon.com Attila Takacs Ericsson 1. Laborc u. Budapest, HUNGARY 1037 Email: attila.takacs@ericsson.com Diego Caviglia Ericsson Via Negrone 1/A Genoa, Italy 16153 Email: diego.caviglia@ericsson.com Alan McGuire BT Group PLC OP6 Polaris House, Adastral Park, Martlesham Heath, Ipswich, Suffolk, IP5 3RE, UK Email: alan.mcguire@bt.com Nurit Sprecher Nokia Siemens Networks, GmbH & Co. KG 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 Fedyk, et. al. Standards Track [Page 18] Generated on: Wed Feb 25 13:53:58 EST 2009