Internet Draft Don Fedyk, Alcatel-Lucent
Category: Standards Track Himanshu Shah, Force10 Networks
Expiration Date: April 14, 2010 Nabil Bitar, Verizon
Attila Takacs, Ericsson
October 14, 2009
Generalized Multiprotocol Label Switching (GMPLS) control of
Ethernet PBB-TE
draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.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 document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may 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
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 April 14, 2010.
Fedyk, et. al. Standards Track [Page 1]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
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 Ethernet Label
Switching Architecture and Framework [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-03.txt October 14, 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
3.1 Shared Forwarding ...................................... 9
3.2 P2P connections procedures for shared forwarding ....... 10
4 Specific Procedures .................................... 10
4.1 P2P Ethernet LSPs ..................................... 10
4.1.1 P2P Path Maintenance ................................... 12
4.2 P2MP Ethernet-LSPs ..................................... 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 ESP-VID related errors ............................... 15
5.1.1 Invalid ESP-VID value in the PBB-TE Ethernet Label .... 15
5.1.2 Allocated ESP-VID range is exhausted .................. 15
5.2 Invalid MAC Address .................................... 15
6 Security Considerations ................................ 16
7 IANA Considerations .................................... 16
8 References ............................................. 16
8.1 Normative References ................................... 16
8.2 Informative References ................................. 17
9 Acknowledgments ........................................ 18
10 Author's Address ....................................... 18
Fedyk, et. al. Standards Track [Page 3]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 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 specification is complementary to with the
GMPLS Ethernet Label Switching Architecture and Framework [ARCH]
document.
1.1. Co-authors
This document is the result of a large team of authors and
contributors. The following is a list of the co-authors:
Don Fedyk (Alcatel-Lucent)
David Allan (Ericsson)
Himanshu Shah (Force10 Networks)
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-03.txt October 14, 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
- 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
- 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
identified by the 3-tuple <ESP-MAC DA, ESP-MAC SA, ESP-VID>. An
ESP is point-to-point (P2P) or point-to-multipoint (P2MP). An ESP
Fedyk, et. al. Standards Track [Page 5]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 2009
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
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
components have internal ports which are connected via an internal
LAN. These internal ports are the Provider Instance Ports (PIPs) and
Fedyk, et. al. Standards Track [Page 6]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 2009
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 describe links
connected to PNPs and CNPs. TE Links are not associated with CBPs or
PIPs.
Note that since multiple internal CBPs may exist an IB-BEB receiving
a PATH message MUST be able to determine the appropriate CBP that is
the termination point of the Eth-LSP. To this end, IB-BEBs SHOULD
advertise 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-03.txt October 14, 2009
Backbone Edge Bridge (BEB)
+------------------------------------------------------+
| <TE - Router ID > |
| |
| I-Component Relay B-Component Relay |
| +-----------------------+ +---------------------+ |
| | +---+ | | B-VID | |
| | |VIP| | | +---+ +---+ | | <TE Link>
| | +---+ | +---|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 | | | | |
Plane | | V label=ESP:VID/MAC DA | |
-----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 <ESP-MAC DA, ESP-MAC SA, ESP-VID> 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-03.txt October 14, 2009
When configuring an 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 <ESP:MAC1(DA), VID1> (60 bits)
GMPLS Downstream Label <ESP:MAC2(DA), VID2> (60 bits)
Upstream PBB-TE ESP 3-tuple <ESP:MAC1, MAC2, VID1> (108 bits)
Downstream PBB-TE ESP 3-tuple <ESP:MAC2, MAC1, VID2> (108 bits)
Table 1 Labels and ESPs
3.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 that are 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.
The forwarding memory savings from shared forwarding 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 known 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 with multiple
paths using a single forwarding entry and optimizing for both
directions. In this scenario the originating switch uses the
Fedyk, et. al. Standards Track [Page 9]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 2009
LABEL_SET and UPSTREAM_LABEL objects to indicate selection of the
shared forwarding labels at both ends.
3.2. P2P connections procedures for 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
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. 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. In
the following we discuss the establishment of bidirectional Eth-LSPs.
Note however that it is also possible to use RSVP-TE to configure
unidirectional ESPs, if the UPSTREAM_LABEL is not included in the
Fedyk, et. al. Standards Track [Page 10]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 2009
PATH message. To initiate a bidirectional Eth-LSP, the initiator
of the PATH message MUST use the procedures outlined in [RFC3473]
with the following specifics:
1) MUST set the LSP encoding type to Ethernet (2) [RFC3471].
2) MUST set the LSP switching type to 802_1 PBB-TE suggested value 40
IANA to define, assigned by this document].
3) SHOULD set the GPID to Ethernet (33) [RFC3471].
4) MUST set the UPSTREAM_LABEL to the ESP-VID1/ESP-MAC1 tuple where
the
ESP-VID1 is administered locally for the local MAC address: MAC1
5) SHOULD set the LABEL_SET or SUGGESTED_LABEL if it chooses to
influence the choice of ESP-VID/ESP-MAC DA.
6) SHOULD look at Call / Connection ID for Carrying I-SID.
Intermediate and egress switch processing is not modified by this
document, i.e., is per [RFC3473]. However, 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 are 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-VID (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 MUST be
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 Eth-LSP as
the PATH and RESV messages follow the same path.
Fedyk, et. al. Standards Track [Page 11]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 2009
4.1.1. 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 an
associated resource does not occur.
Where individual paths in a protection group are modified, signaling
procedures MAY be combined with Protection Switching (PS)
coordination to administratively force PS switching operations such
that modification is only ever performed on the protection path.
4.2. P2MP Ethernet-LSPs
PBB-TE supports P2MP VID/Multicast MAC (MMAC) forwarding. In this
case the PBB-TE Ethernet Label consists of a VID and a Group MAC
address. 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.3. PBB-TE Ethernet Label
The PBB-TE Ethernet Label is a new generalized label with the
following format:
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 MUST be used for both P2P and P2MP Eth-LSPs. For P2P Eth-
Fedyk, et. al. Standards Track [Page 12]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 2009
LSPs 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 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
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-
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
LSP_ATTRIBUTES objects. The format is depicted below.
Fedyk, et. al. Standards Track [Page 13]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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(Type 1): 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).
- I-SID: 24 bits
The I-SID value identifies a particular backbone service
instance.
Fedyk, et. al. Standards Track [Page 14]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 2009
5. Error conditions
The following errors identify Eth-LSP specific problems.
5.1. ESP-VID related errors
The network operator administratively selects a
set of VLAN Identifiers that can be used to setup ESPs.
Consequently, any VID outside the allocated range is invalid and an
error MUST be generated where the mismatch is discovered.
5.1.1. Invalid ESP-VID value in the PBB-TE Ethernet Label
If a bridge is not configured to use the ESP-VID value, carried in
the Label object, for PBB-TE ESPs, it MUST immediately generate an
error: Routing problem (24) / Unacceptable label value (6). Handling
of this error is according to [RFC3209].
Note, this error may be originated by any switch along the path.
5.1.2. Allocated ESP-VID range is exhausted
The destination bridge after receiving the PATH message has to
allocate a VID, which together with its MAC address will constitute
the PBB-TE Ethernet Label. Depending on the size of the allocated
VLAN range and the number of Eth-LSPs terminated on a particular
bridge, it is possible that the available VIDs are exhausted and
hence no PBB-TE Ethernet Label can be allocated. In this case the
destination bridge SHOULD generate a PathErr message with error code:
Routing problem (24) and error value: PBB-TE Ethernet Label VID
allocation failure (35?) [the new error sub-code to be allocated by
IANA]
5.2. Invalid MAC Address
IEEE defines a set of reserved MAC addresses that have special
meaning, processing and follow specific forwarding rules. These
addresses cannot be used for PBB-TE ESPs. In the case the PBB-TE
Ethernet Label refers to such a MAC address, a bridge encountering
the mismatch MUST immediately generate an error: Routing problem (24)
/ Unacceptable label value (6). Handling of this error is according
to [RFC3209].
Fedyk, et. al. Standards Track [Page 15]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 2009
6. Security Considerations
This document does not introduces new security issues; the
considerations in [RFC4872] and [RFC4873] apply.
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. PBB-TE has been
designed to interwork with legacy VLANs and the VLANs provide
isolation from Ethernet legacy control planes.
7. IANA Considerations
- Assign a new Switching Type: "802_1 PBB-TE" (suggested value 40)
in the GMPLS Signaling Parameters / Switching Types registry.
- Assign a new globally defined error value: "PBB-TE Ethernet Label
VID allocation failure" (suggested value: 35?) under the
"Routing problem" (24) error code in the RSVP Parameters / Error
Codes and Globally-Defined Error Value Sub-Codes registry.
- Assign a new type from the Attributes TLV Space in the RSVP-TE
Parameters registry (suggested value 2) for the Service ID TLV
that is carried in the LSP_ATTRIBUTES Object (class = 197, C-Type
= 1) [RFC5420].
- Assign a new type (suggested value 2) for the Service ID TLV that
is carried in the CALL_ATTRIBUTES Object (class = 201, C-Type =
1) [MLN-EXT].
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.
Fedyk, et. al. Standards Track [Page 16]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 2009
[RFC3471] Berger, L. et.al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description" IETF RFC 3471,
January 2003.
[RFC3473] Berger, L. et.al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", IETF RFC 3473, January 2003.
[RFC3945] Mannie, E. et.al., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", IETF RFC 3945, October 2004.
[MLN-EXT] Papadimitriou, D. et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Protocol Extensions for Multi-Layer
and Multi-Region Networks (MLN/MRN)", work in progress.
[RFC5420] Farrel, A. Ed., "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE), IETF RFC 5420, February 2009.
8.2. Informative References
[IEEE 802.1ay] "IEEE Standard for Local and Metropolitan Area
Networks - Virtual Bridged Local Area Networks
- Amendment : Provider Backbone Bridges Traffic Engineering
(2009).
[IEEE 802.1ag] "IEEE Standard for Local and Metropolitan Area
Networks - Virtual Bridged Local Area Networks
- Amendment 5: 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)
[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", IETF RFC 4655, August 2006
[RFC4872] Lang, J. et.al., "RSVP-TE Extensions in support of End-to-
End
Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery
", RFC 4872, May 2007.
Fedyk, et. al. Standards Track [Page 17]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 2009
[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
Alcatel-Lucent
Groton, MA, 01450
Phone: +1-978-467-5645
Email: donald.fedyk@alcatel-lucent.com
David Allan
Ericsson
Email: david.i.allan@ericsson.com
Himanshu Shah
Force10 Networks
30 Nagog Park,
Acton, MA 01720
Email: hshah@force10networks.com
Nabil Bitar
Verizon,
40 Sylvan Rd.,
Waltham, MA 02451
Email: nabil.n.bitar@verizon.com
Fedyk, et. al. Standards Track [Page 18]
Internet-Draft draft-ietf-ccamp-gmpls-ethernet-pbb-te-03.txt October 14, 2009
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 19]
Generated on: Wed Oct 14 13:52:17 EDT 2009
