Network Working Group A. Takacs Internet-Draft B. Tremblay Intended status: Informational Ericsson Expires: April 30, 2009 R. Theillaud Marben Products K. Ogaki KDDI R&D Laboratories, Inc. October 27, 2008 Report on first GMPLS Controlled Ethernet tests draft-takacs-ccamp-gels-tests-00 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 on April 30, 2009. Takacs, et al. Expires April 30, 2009 [Page 1] Internet-Draft Firts GELS tests October 2008 Abstract In this memo we report on the first GMPLS controlled Ethernet interoperability test involving three independent implementations. We also briefly introduce our GMPLS controlled Ethernet test-beds and identify the implemented GMPLS extensions. Note, this memo does not intend to specify any GMPLS extension. Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. GELS interoperability tests at ISOCORE . . . . . . . . . . . . 5 3. GELS implementation at KDDI R&D Labs . . . . . . . . . . . . . 7 4. GELS implementation at Marben Products . . . . . . . . . . . . 8 5. GELS implementation at Ericsson Research . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Takacs, et al. Expires April 30, 2009 [Page 2] Internet-Draft Firts GELS tests October 2008 1. Background Ethernet standards are being amended in IEEE to equip Ethernet with new features required for Wide Area Network (WAN) deployment. The relevant extensions are 1) Connectivity Fault Management (CFM) [IEEE-CFM], 2) Provider Bridging (PB) [IEEE-PB], 3) Provider Backbone Bridging (PBB) [IEEE-PBB] and 4) Provider Backbone Bridging - Traffic Engineering (PBB-TE) [IEEE-PBBTE]). CFM specifies Operations, Administration, and Maintenance (OAM) mechanisms for Ethernet networks. It defines three mechanisms. 1) Continuity Check (CC): to allow periodical liveliness monitoring. 2) Loop-back (LB): for on-demand failure verification. 3) Link-trace (LT): for route recording and failure localisation. PB and PBB are enhancing Ethernet scalability. With PB, a new VLAN tag, the Service VLAN (S-VLAN) tag is introduced to allow providers to use a separate VLAN space while transparently maintaining the customer VLAN (C-VLAN) information. The new S-VLAN tag (S-TAG) has been assigned a new Ethertype (88-a8) while the Ethertype (81-00) of the "original" VLAN tag is maintained to identify C-VLAN tags (C-TAG). In PB we can distinguish edge bridges (Provider Edge Bridge - PEB), which may process C-TAGs and add the S-TAG; and core bridges (Provider Core Bridge - PCB), which only process S-TAGs . PBB allows a full separation of the customer and provider address spaces by encapsulating customer frames adding a "backbone" MAC header. This way, both the MAC addresses and the whole VLAN space is in the control of the provider. To refer to the fields of the the encapsulation header we prepend "Backbone" to the names of the respective fields: Backbone Destination Address (B-DA), Backbone Source Address (B-SA) and Backbone VLAN (B-VLAN). The B-VLAN uses the same Ethertype as the S-VLAN. In addition to the "Backbone" MAC header, a new tag, the Service Instance Tag (I-TAG) (new Ethertype assigned) is added when customer frames are encapsulated. The I-TAG, among others, includes a 24bit Service Instance Identifier (I-SID) field. The I-SID unambiguously identifies customer services. In PBB we can distinguish edge bridges (Backbone Edge Bridge - BEB), which process customer frames and add the backbone MAC header and I-TAG; and core bridges (Backbone Core Bridge - BCB) which are essentially PCBs, only processing S/B-TAGs. PBB-TE decouples the Ethernet data and control planes by explicitly supporting external control/management mechanisms to configure static filtering entries in bridges and create explicitly routed Ethernet connections. PBB-TE refers to Ethernet connections as Ethernet Switched Paths (ESPs). An ESP is identified by a 3-tuple including Takacs, et al. Expires April 30, 2009 [Page 3] Internet-Draft Firts GELS tests October 2008 its destination and source addresses and VLAN identifier (VID); is short: [ESP-MAC DA, ESP-MAC SA, ESP-VID]. In addition PBB-TE defines mechanisms for 1:1 protection switching of bidirectional Ethernet connections. In IETF the GMPLS controlled Ethernet Label Switching (GELS) work is extending the GMPLS control plane for PBB-TE Ethernet networks [GELS-Framework] [GELS-PBBTE]. We refer to GMPLS established PBB-TE connections as Ethernet LSPs. GELS enables the application of MPLS-TE and GMPLS provisioning and recovery features in Ethernet networks. The GELS framework [GELS-Framework] describes the general principles of applying GMPLS for Ethernet. Ethernet technology specific traffic parameters are described in [Ethernet-Traffic]. Technology specific extensions for PBB-TE are specified in [GELS-PBBTE]. GMPLS RSVP-TE extensions to configure Ethernet OAM is described in [OAM-CONF-FWK] and [GMPLS-Ethernet-OAM-CONF]. Takacs, et al. Expires April 30, 2009 [Page 4] Internet-Draft Firts GELS tests October 2008 2. GELS interoperability tests at ISOCORE Three parties: Ericsson, KDDI R&D Labs and Marben Products, participated in GELS tests this fall at the ISOCORE interoperability demo. The test topology is depicted below showing which participants provided the nodes. +----+ +----+ |KDDI|----------|KDDI| /+----+ +----+\ / \----+ +------/ \ +--------+ | | +--------+ |Ericsson|------)--)---------|Ericsson| +--------+ | | +--------+ \ | | \ +------+ / ------|Marben|-------- +------+ Various LSP establishment scenarios were tested successfully including recovery scenarios with LSP re-routing. In the case of re-routing the Marben node initiated the Ethernet LSP creation and introduced a PROTECTION object with LSP flags set to Full re-routing in the PATH message to indicate that full rerouting protection was requested for this LSP. Since we wanted to test control plane functionality we relied on RSVP-TE signalling to initiate the restoration. Hence, once the ESP was established, we simulated a failure at the egress node by sending a fake continuity check CFM failure event to the egress control plane stack. The egress node sent a Notify message including a Notify Error with a sub-value of LSP Locally failed directly to the ingress node. This triggered a new path computation in the ingress node. (Note that in the case of bidirectional LSPs we can rely on Ethernet OAM to convey this information to the ingress node via Remote Defect Indication (RDI) and trigger a local failure notification there.) The new ESP has been established using a different path. Once the new ESP is established, the ingress node sent a PathTear message to delete the original failed LSP. Although during the tests some discrepancies were found, interestingly there was no problem associated to the actual GMPLS extensions to control Ethernet LSPs. The only related issues were differences in the use and interpretation of the Ethernet SENDER_TSPEC/FLOW_SPEC objects [Ethernet-Traffic] and the way the termination point of an Ethernet LSP is determined in general cases where an egress BEB may utilise multiple internal Customer Backbone Ports. Takacs, et al. Expires April 30, 2009 [Page 5] Internet-Draft Firts GELS tests October 2008 KDDI R&D Labs has not implemented Ethernet SENDER_TSPEC/FLOW_SPEC objects, hence for Ethernet-LSPs between KDDI R&D Labs and the other participants the Intserv SENDER_TSPEC/FLOW_SPEC object was used instead. Marben Products and Ericsson supported the Ethernet SENDER_TSPEC/ FLOW_SPEC objects but needed to agree on a common interpretation of the Index field. The selected approach was identical to the OIF interpretation. That is, to use the Index field as a bit field where each bit corresponds to a CoS. This solution simplified the number of objects required to be inserted into the path message while supported all CoSs available in Ethernet. However, after the test event a discussion with the author of the [Ethernet-Traffic] document revealed that the interpretation is not correct and the field should not be interpreted as single bits. Instead values 0 to 7 are used to refer to single class types while the other values should be used as indexes to pre-provisioned CoS maps. It was agreed that the author of the [Ethernet-Traffic] will clarify the use of the Index field in a subsequent version of his document. The other issue related to how the egress Customer Backbone Port (CPB) is identified. For this purpose both Marben Products and Ericsson relied on the use of Egress Control [RFC4003] and interpreted the Interface ID of the last hop in the ERO as the CBP port ID. This may not be the best solution to convey CBP port identification hence further discussion is needed how to best determine the termination point of the Ethernet LSP. This issue relates to the fact that CBP ports, on which PBB-TE ESP are terminated are internal ports of egress BEBs. Takacs, et al. Expires April 30, 2009 [Page 6] Internet-Draft Firts GELS tests October 2008 3. GELS implementation at KDDI R&D Labs To investigate the applicability of GMPLS controlled PBB-TE, KDDI R&D Labs has implemented the main features of [GELS-PBBTE] by extending a GMPLS protocol stack to control an external PBB-TE capable Ethernet switch. The implemented GELS extensions are summarised below. o The Ethernet Label format and Ethernet LSP establishment is according to [GELS-PBBTE]. o The Interface Switching Capability Descriptor in an OSPF-TE LSA is with the Interface Switching Capability of 802_1 PBB_TE (TBA by IANA). o To request Ethernet LSPs, we use the Generalized Label Request Object with the following parameters: Switching Type: 802_1 PBB-TE, LSP Encoding Type Ethernet (2) and G-PID Ethernet (33). Takacs, et al. Expires April 30, 2009 [Page 7] Internet-Draft Firts GELS tests October 2008 4. GELS implementation at Marben Products Marben Products has enhanced its GMPLS protocol stack implementation and its GMPLS emulator, in order to support GELS. The emulated topology consists of seven nodes in a mesh topology. Each node can fulfill both BEB or BCB roles. Our implementation supports the following. o The Ethernet SENDER_TSPEC/FLOW_SPEC objects from [Ethernet-Traffic]. It is possible for multiple class types to share the same bandwidth profile. In order to do so, the Index field in the Ethernet Bandwidth Profile TLV is used as a bit field, one bit per class type. It was agreed upon to use this encoding for the Isocore demonstration, although it was recognized that this may not be the way this draft intends to use that field to specify multiple class types. o The GMPLS Ethernet Label format is according to [GELS-PBBTE]. o No LABEL_SET is used during Ethernet LSP signaling. Hence the B-VID may be different for each direction of a bi-directional LSPs. o A new switching type value is used for PBB-TE, in RSVP-TE Generalized LABEL_REQUEST object and OSPF-TE LSAs (Interface Switching Capability descriptor). o End-to-end full rerouting [RFC4872] using SE style and make- before-break (MBB) procedure. Different B-VIDs are used for the rerouting LSP. o 1:1 end-to-end protection [RFC4872]. Different B-VIDs are used for the working and protection LSPs. o The Ethernet OAM Configuration TLV in the LSP_ATTRIBUTES object, as defined in the 01 version of [GMPLS-Ethernet-OAM-CONF] draft. o Egress control [RFC4003] is used to add in explicit routes a final hop specifying the identifier of the Egress Customer Backbone Port (CBP). Takacs, et al. Expires April 30, 2009 [Page 8] Internet-Draft Firts GELS tests October 2008 5. GELS implementation at Ericsson Research In a lab environment, Ericsson Research has implemented a GELS test- bed. We implemented specifics of the PB, PBB and PBB-TE data plane, CFM Ethernet OAM, and GMPLS extensions. To experiment with GMPLS, we modified our GMPLS protocol stack that is in use to control SDH equipment. By selecting a deployed protocol stack we got first hand experience on the extent of complexity of adding the Ethernet related extensions. As expected, it turned out that the required additions are very small. One of our requirements was to provide resiliency performance similar to that provided by SDH. We benefited from using the protocol stack developed for optical networks, since we got all the protection switching and restoration features readily available in the control plane. Due to the fact that PBB-TE only supports 1:1 bidirectional protection switching we focused on this protection type. The operational specifics of PBB-TE [IEEE-PBBTE] required that we extended the PROTECTION object to explicitly signal when revertive protection is requested. See [Revertive-PS]. For fast detection of data plane failures we implemented CFM Ethernet OAM. Our hardware supports CC messages at 3.3ms rate, hence providing 50ms fail-over is easily achieved in the test-bed. To simplify the configuration of connectivity monitoring, when an Ethernet LSP is signalled the associated monitoring entities are automatically established. Furthermore, GMPLS signalling is extended to enable/disable connectivity monitoring of a particular Ethernet LSP. For relevant RSVP-TE extensions see [OAM-CONF-FWK] and [GMPLS-Ethernet-OAM-CONF]. Below is the list of GMPLS RSVP-TE extensions we implemented thus far. o The Ethernet Label format and Ethernet LSP establishment is according to [GELS-PBBTE]. o We implemented the Ethernet Traffic Parameters TLV [Ethernet-Traffic]. o We added a new TLV to the LSP_ATTRIBUTES object for explicit control of Ethernet OAM follwoing an earlier version of what is proposed in [OAM-CONF-FWK] and [GMPLS-Ethernet-OAM-CONF]. o We added a new bit to the ADMIN_STATUS Object to enable/disbale connectivity monitoring [OAM-CONF-FWK]. Takacs, et al. Expires April 30, 2009 [Page 9] Internet-Draft Firts GELS tests October 2008 o We extended the PROTECTION Object to explicitly control reversion and added a new bit and a new WTR field similar to what is proposed in [Revertive-PS]. o To request Ethernet LSPs, we use the Generalized Label Request Object with the following parameters: Switching Type: L2SC (51), LSP Encoding Type Ethernet (2) and G-PID Ethernet (33). Takacs, et al. Expires April 30, 2009 [Page 10] Internet-Draft Firts GELS tests October 2008 6. IANA Considerations No request is made to IANA. Takacs, et al. Expires April 30, 2009 [Page 11] Internet-Draft Firts GELS tests October 2008 7. Security Considerations No security issues raised in this document. Takacs, et al. Expires April 30, 2009 [Page 12] Internet-Draft Firts GELS tests October 2008 8. Acknowledgements We would like to thank everyone who supported and contributed to the GELS interop event at the Isocore demo this fall. Takacs, et al. Expires April 30, 2009 [Page 13] Internet-Draft Firts GELS tests October 2008 9. References [Ethernet-Traffic] "Ethernet Traffic Parameters", Internet Draft, draft-ietf-ccamp-ethernet-traffic-parameters-05; work in progress. [GELS-Framework] "GMPLS Ethernet Label Switching Architecture and Framework", Internet Draft, draft-ietf-ccamp-gmpls-ethernet-arch-03; work in progress. [GELS-PBBTE] "GMPLS control of Ethernet", Internet Draft, draft-ietf-ccamp-gmpls-ethernet-pbb-te-01; work in progress. [GMPLS-Ethernet-OAM-CONF] "GMPLS RSVP-TE Extensions for Ethernet OAM Configuration", Internet Draft, draft-takacs-ccamp-rsvp-te-eth-oam-ext-03; work in progress. [IEEE-CFM] "IEEE 802.1ag, Draft Standard for Connectivity Fault Management", work in progress. [IEEE-PB] "IEEE 802.1Qad Draft Standard for Provider Bridging", . [IEEE-PBB] "IEEE 802.1Qah Draft Standard for Provider Backbone Bridging", work in progress. [IEEE-PBBTE] "IEEE 802.1Qay Draft Standard for Provider Backbone Bridging Traffic Engineering", work in progress. [OAM-CONF-FWK] "OAM Configuration Framework for GMPLS RSVP-TE", Internet Draft, draft-takacs-ccamp-oam-configuration-fwk-00; work in progress. [RFC4003] "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005. [RFC4872] "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007. Takacs, et al. Expires April 30, 2009 [Page 14] Internet-Draft Firts GELS tests October 2008 [Revertive-PS] "GMPLS RSVP-TE recovery extension for data plane initiated reversion", Internet Draft, draft-takacs-ccamp-revertive-ps-02; work in progress. Takacs, et al. Expires April 30, 2009 [Page 15] Internet-Draft Firts GELS tests October 2008 Authors' Addresses Attila Takacs Ericsson Laborc u. 1. Budapest, 1037 Hungary Email: Attila.Takacs@ericsson.com Benoit Tremblay Ericsson 8400 Decarie Montreal, Quebec H4P 2N2 Canada Email: Benoit.C.Tremblay@ericsson.com Remi Theillaud Marben Products 176 rue Jean Jaures Puteaux, 92800 France Email: remi.theillaud@marben-products.com Kenichi Ogaki KDDI R&D Laboratories, Inc. 2-1-15 Ohara Kamifukuoka Saitama, 356-8502 Japan Email: ogaki@kddilabs.jp Takacs, et al. Expires April 30, 2009 [Page 16] Internet-Draft Firts GELS tests October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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. Intellectual Property 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. Takacs, et al. Expires April 30, 2009 [Page 17]