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]