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

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/