draft-ietf-ccamp-gmpls-ethernet-pbb-te-04.txt   draft-ietf-ccamp-gmpls-ethernet-pbb-te-05.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: November 3, 2010 Nabil Bitar, Verizon Expiration Date: February 18, 2011 Nabil Bitar, Verizon
Attila Takacs, Ericsson Attila Takacs, Ericsson
May 3, 2010 August 18, 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-04.txt draft-ietf-ccamp-gmpls-ethernet-pbb-te-05.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 November 3, 2010. This Internet-Draft will expire on February 18, 2011.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. 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 [RFC5828] and describes the Switching Architecture and Framework and describes the technology
technology specific aspects of GMPLS control for Provider Backbone specific aspects of GMPLS control for Provider Backbone Bridge
Bridge Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary Traffic Engineering (PBB-TE). The necessary GMPLS extensions and
GMPLS extensions and mechanisms are described to establish Ethernet mechanisms are described to establish Ethernet PBB-TE point to point
PBB-TE point to point (P2P) and point to multipoint (P2MP) (P2P) and point to multipoint (P2MP) connections. This document
connections. This document supports, but does not modify, the 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
1.1 Co-authors ............................................. 4 1.1 Co-authors ............................................. 4
2 Terminology ............................................ 5 2 Terminology ............................................ 5
2.1 PBB-TE and GMPLS Terminology ........................... 5 2.1 PBB-TE and GMPLS Terminology ........................... 5
3 Creation and Maintenance of PBB-TE paths using GMPLS ... 6 3 Creation and Maintenance of PBB-TE paths using GMPLS ... 6
3.1 Shared Forwarding ...................................... 9 3.1 Shared Forwarding ...................................... 9
3.2 P2P connections procedures for shared forwarding ....... 10 3.2 P2P Connections Procedures for Shared Forwarding ....... 10
4 Specific Procedures .................................... 10 4 Specific Procedures .................................... 10
4.1 P2P Ethernet LSPs ..................................... 10 4.1 P2P Ethernet LSPs ..................................... 10
4.1.1 P2P Path Maintenance ................................... 12 4.1.1 P2P Path Maintenance ................................... 11
4.2 P2MP Ethernet-LSPs ..................................... 12 4.2 P2MP Ethernet-LSPs ..................................... 12
4.3 PBB-TE Ethernet Label .................................. 12 4.3 PBB-TE Ethernet Label .................................. 12
4.4 Protection Paths ....................................... 13 4.4 Protection Paths ....................................... 13
4.5 Service Instance Identification ....................... 13 4.5 Service Instance Identification ....................... 13
5 Error conditions ....................................... 15 5 Error conditions ....................................... 15
5.1 ESP-VID related errors ............................... 15 5.1 ESP-VID related errors ............................... 15
5.1.1 Invalid ESP-VID value in the PBB-TE Ethernet Label .... 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.1.2 Allocated ESP-VID range is exhausted .................. 15
5.2 Invalid MAC Address .................................... 15 5.2 Invalid MAC Address .................................... 16
6 Security Considerations ................................ 16 6 Security Considerations ................................ 16
7 IANA Considerations .................................... 16 7 IANA Considerations .................................... 17
8 References ............................................. 16 8 References ............................................. 17
8.1 Normative References ................................... 16 8.1 Normative References ................................... 17
8.2 Informative References ................................. 17 8.2 Informative References ................................. 18
9 Acknowledgments ........................................ 18 9 Acknowledgments ........................................ 19
10 Author's Address ....................................... 18 10 Author's Address ....................................... 19
Conventions used in this document Conventions used in this document
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)
skipping to change at page 5, line 8 skipping to change at page 5, line 8
Nabil Bitar (Verizon) Nabil Bitar (Verizon)
Attila Takacs (Ericsson) Attila Takacs (Ericsson)
Diego Caviglia (Ericsson) Diego Caviglia (Ericsson)
Alan McGuire (BT) Alan McGuire (BT)
Nurit Sprecher (Nokia Siemens Networks) Nurit Sprecher (Nokia Siemens Networks)
Lou Berger (LabN) Lou Berger (LabN)
2. Terminology 2. Terminology
In addition to well understood GMPLS terms, this memo uses In addition to well understood GMPLS terms, this memo uses
terminology from IEEE 802.1 [IEEE 802.1Qah] [IEEE 802.1Qay]: terminology from IEEE 802.1 [IEEE 802.1ah] [IEEE 802.1Qay]:
- BCB Backbone Core Bridge - BCB Backbone Core Bridge
- BEB Backbone Edge Bridge - BEB Backbone Edge Bridge
- B-MAC Backbone MAC - B-MAC Backbone MAC
- B-VID Backbone VLAN ID - B-VID Backbone VLAN ID
- B-VLAN Backbone VLAN - B-VLAN Backbone VLAN
- CBP Customer Backbone Port - CBP Customer Backbone Port
- CCM Continuity Check Message - CCM Continuity Check Message
- CNP Customer Network Port - CNP Customer Network Port
- C-MAC Customer MAC - C-MAC Customer MAC
skipping to change at page 5, line 33 skipping to change at page 5, line 33
- ESP-MAC DA ESP Destination MAC Address - ESP-MAC DA ESP Destination MAC Address
- ESP-VID ESP VLAN ID - ESP-VID ESP VLAN ID
- Eth-LSP Ethernet Label Switched Path - Eth-LSP Ethernet Label Switched Path
- IB-BEB A BEB comprising of both I and B components - IB-BEB A BEB comprising of both I and B components
- I-SID Ethernet Service Instance Identifier - I-SID Ethernet Service Instance Identifier
- MAC Media Access Control - MAC Media Access Control
- PBB Provider Backbone Bridges - PBB Provider Backbone Bridges
- PBB-TE Provider Backbone Bridges Traffic Engineering - PBB-TE Provider Backbone Bridges Traffic Engineering
- PIP Provider Instance Port - PIP Provider Instance Port
- PNP Provider Network Port - PNP Provider Network Port
- PS Protection Switching
- P2P Point to Point - P2P Point to Point
- P2MP Point to Multipoint - P2MP Point to Multipoint
- SVL Shared VLAN Learning - SVL Shared VLAN Learning
- TESI TE Service Instance - TESI TE Service Instance
- VID VLAN ID - VID VLAN ID
- VLAN Virtual LAN - VLAN Virtual LAN
2.1. PBB-TE and GMPLS Terminology 2.1. PBB-TE and GMPLS Terminology
The PBB-TE specification [IEEE 802.1Qay] defines some additional The PBB-TE specification [IEEE 802.1Qay] defines some additional
terminology to clarify the PBB-TE functions. We repeat these here in terminology to clarify the PBB-TE functions. We repeat these here in
expanded context to translate from IEEE to GMPLS terminology. expanded context to translate from IEEE to GMPLS terminology. The
terms bridge and switch are used interchangeably in this document.
The signaling extensions described here apply equally well to a PBB-
TE capable bridge supporting GMPLS signaling or to a GMPLS capable
switch supporting Ethernet PBB-TE forwarding.
- Ethernet Switched Path (ESP): - Ethernet Switched Path (ESP):
A provisioned traffic engineered unidirectional connectivity path A provisioned traffic engineered unidirectional connectivity path
between two or more Customer Backbone Ports (CBPs) which extends between two or more Customer Backbone Ports (CBPs) which extends
over a Provider Backbone Bridge Network (PBBN). The path is over a Provider Backbone Bridge Network (PBBN). The path is
identified by the 3-tuple <ESP-MAC DA, ESP-MAC SA, ESP-VID>. An 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 ESP is point-to-point (P2P) or point-to-multipoint (P2MP). An ESP
is analogous to a (unidirectional) point-to-point or point-to- is analogous to a (unidirectional) point-to-point or point-to-
multipoint LSP. We use the term Ethernet-LSP (Eth-LSP) for GMPLS multipoint LSP. We use the term Ethernet-LSP (Eth-LSP) for GMPLS
established ESPs. established ESPs.
skipping to change at page 6, line 35 skipping to change at page 6, line 42
to-point ESPs associated with a point-to-point TESI are co- to-point ESPs associated with a point-to-point TESI are co-
routed. Support for a point-to-point TE services which comprises routed. Support for a point-to-point TE services which comprises
non co-routed ESPs is problematic, and is not defined in this non co-routed ESPs is problematic, and is not defined in this
standard. Hence, a GMPLS bidirectional LSP is analogous to a P2P standard. Hence, a GMPLS bidirectional LSP is analogous to a P2P
TE Service instance. We use the term bidirectional Ethernet-LSP TE Service instance. We use the term bidirectional Ethernet-LSP
for GMPLS established P2P PBB-TE Service instances. for GMPLS established P2P PBB-TE Service instances.
3. Creation and Maintenance of PBB-TE paths using GMPLS 3. Creation and Maintenance of PBB-TE paths using GMPLS
IEEE PBB-TE is a connection oriented Ethernet technology. PBB-TE ESPs IEEE PBB-TE is a connection oriented Ethernet technology. PBB-TE ESPs
are created switch by switch by simple configuration of Ethernet are created bridge by bridge (or switch by switch) by simple
forwarding entries. This document describes the use of GMPLS as a configuration of Ethernet forwarding entries. This document describes
valid control plane for the set-up, teardown, protection and the use of GMPLS as a valid control plane for the set-up, teardown,
recovery of ESPs and TESIs and specifies the required RSVP-TE protection and recovery of ESPs and TESIs and specifies the required
extensions for the control of PBB-TE service instances. RSVP-TE extensions for the control of PBB-TE service instances.
PBB-TE ESP and services are always originated and terminated on IB- 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 Backbone Edge Bridges (IB-BEBs). IB-BEBs are constituted of I and B
components, this is illustrated in Figure 1. components, this is illustrated in Figure 1.
An Ethernet service supported by a PBB-TE TESI is always attached to 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 a Customer Network Port (CNP) of the I-component. A Service Instance
Identifier (I-SID) is assigned for the service. The I and B Identifier (I-SID) is assigned for the service. I-SIDs are only
looked at by source and destination (edge) bridges so I-SIDs are
transparent to path operations and MAY be signaled. The I and B
components have internal ports which are connected via an internal components have internal ports which are connected via an internal
LAN. These internal ports are the Provider Instance Ports (PIPs) and LAN. These internal ports are the Provider Instance Ports (PIPs) and
Customer Backbone Ports (CBPs). PIPs and CBPs are not visible outside Customer Backbone Ports (CBPs). PIPs and CBPs are not visible outside
the IB-BEB. ESPs are always originated and terminated on CBP ports the IB-BEB. ESPs are always originated and terminated on CBP ports
and use the MAC address of that port. The I-Component encapsulates 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 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 complete Ethernet MAC header with an ESP-MAC DA and ESP-MAC SA. The
B-Component adds the ESP-VID. B-Component adds the ESP-VID.
GMPLS is being defined here to establish ESPs and TESIs. As it can be This document defines extensions to GMPLS to establish ESPs and
seen from the above this requires configuration of both the I and B TESIs. As it can be seen from the above this requires configuration
components of the IB-BEBs connected by the ESPs. 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- 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 BEBs and Backbone Core Bridges (BCBs), and TE Links describe links
connected to PNPs and CNPs. TE Links are not associated with CBPs or connected to PNPs and CNPs. TE Links are not associated with CBPs or
PIPs. PIPs.
Note that since multiple internal CBPs may exist an IB-BEB receiving 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 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 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 advertise the CNP TE Links in the GMPLS control plane and RSVP-TE
skipping to change at page 8, line 40 skipping to change at page 8, line 40
V | V V | V
+----+ | +-----+ +----+ | +-----+
Data | | | | | Data | | | | |
Plane | | V label=ESP:VID/MAC DA | | Plane | | V label=ESP:VID/MAC DA | |
-----N N----------------------------N N---------- -----N N----------------------------N N----------
| | PBB-TE | | \ Network | | PBB-TE | | \ Network
| | / | Or | | / | Or
+----+ /+-----+ Customer +----+ /+-----+ Customer
BCB ESP:MAC IB-BEB Facing BCB ESP:MAC IB-BEB Facing
Ethernet Ethernet
Ports Ports
Figure 2 Ethernet/GMPLS Addressing & Label Space Figure 2 Ethernet/GMPLS Addressing & Label Space
PBB-TE defines the tuple of <ESP-MAC DA, ESP-MAC SA, ESP-VID> as a 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 unique connection identifier in the data plane but the forwarding
operation only uses the ESP-MAC DA and the ESP-VID in each direction. 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 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 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. that ESP-VIDs for two ESPs that form a P2P TESI be the same.
skipping to change at page 9, line 38 skipping to change at page 9, line 38
destination forwarding entries for packets from any source within a destination forwarding entries for packets from any source within a
VLAN to a destination. When setting up P2P PBB-TE connections for VLAN to a destination. When setting up P2P PBB-TE connections for
multiple sources sharing a common destination this capability MAY be multiple sources sharing a common destination this capability MAY be
preserved provided certain requirements are met. We refer to this preserved provided certain requirements are met. We refer to this
capability as Shared Forwarding. Shared forwarding is invoked based capability as Shared Forwarding. Shared forwarding is invoked based
on policy when conditions are met. It is a local decision by label on policy when conditions are met. It is a local decision by label
allocation at each end plus the path constraints. Shared forwarding allocation at each end plus the path constraints. Shared forwarding
has no impact on the actual paths that are setup, but it allows the has no impact on the actual paths that are setup, but it allows the
reduction of forwarding entries. Shared forwarding paths are reduction of forwarding entries. Shared forwarding paths are
identical in function to independently routed paths that share a path identical in function to independently routed paths that share a path
from an intersecting switch or link except they share a single from an intersecting bridge 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 [RFC4655] or other planning style of Use of a Path Computation Element [RFC4655] or other planning style
tool with more complete knowledge of the network configuration is a of tool with more complete knowledge of the network configuration is
way to impose pre-selection of shared forwarding with multiple paths a way to impose pre-selection of shared forwarding with multiple
using a single forwarding entry and optimizing for both directions. paths using a single forwarding entry and optimizing for both
In this scenario the originating switch uses the LABEL_SET and directions. In this scenario the originating bridge uses the
UPSTREAM_LABEL objects to indicate selection of the shared forwarding LABEL_SET and UPSTREAM_LABEL objects to indicate selection of the
labels at both ends. shared forwarding 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 ESP header contains sufficient information to
path. Resources can continue to be allocated per LSP with Shared identify the flow to which a packet belongs. Resources can continue
forwarding. to be allocated per LSP with Shared forwarding.
VLAN tagged Ethernet packets include priority marking. Priority bits VLAN tagged Ethernet packets include priority marking. Priority bits
MAY be used to indicate class of Service (COS) and drop priority. MAY be used to indicate Class of Service (COS) and drop priority.
Thus, traffic from multiple COSs could be multiplexed on the same 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 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 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 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. decoupled from the actual steering of the packet at any given bridge.
A switch terminating an Eth-LSP will frequently have more than one A bridge terminating an Eth-LSP will frequently have more than one
suitable candidate for sharing a forwarding entry (common ESP- suitable candidate for sharing a forwarding entry (common ESP-
VID/ESP-MAC DA, unique ESP-MAC SA). It is a local decision of how 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 this is performed but a good choice is a path that reduces the
shared forwarding. requirement for new forwarding entries by reusing common existing
paths.
The concept of bandwidth management still applies equally well with The concept of bandwidth management still applies equally well with
shared forwarding. As an example consider a PBB-TE edge switch that shared forwarding.
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. Specific Procedures
4.1. P2P Ethernet LSPs 4.1. P2P Ethernet LSPs
Note, PBB-TE is designed to be bidirectional and symmetrically routed Note, PBB-TE is designed to be bidirectional and symmetrically routed
just like Ethernet. That is, complete and proper functionality of just like Ethernet. That is, complete and proper functionality of
Ethernet protocols is only guaranteed for bidirectional Eth-LSPs. In Ethernet protocols is only guaranteed for bidirectional Eth-LSPs. In
the following we discuss the establishment of bidirectional Eth-LSPs. the following we discuss the establishment of bidirectional Eth-LSPs.
skipping to change at page 11, line 24 skipping to change at page 11, line 21
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) MAY carry an I-SID via Call / Connection ID [RFC4974]. 6) MAY carry an I-SID via Call / Connection ID [RFC4974].
Intermediate and egress switch processing is not modified by this Intermediate and egress bridge 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
derived from the RSVP_HOP object and the ESP-VID1 and ESP-MAC1 derived from the RSVP_HOP object and the ESP-VID1 and ESP-MAC1
included in the PBB-TE Ethernet Label constitute the static entry. included in the PBB-TE Ethernet Label constitute the static entry.
At the destination, an ESP-VID (ESP-VID2) is allocated for the local 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 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 object in the RESV message. As with the PATH message, intermediate
switch processing is per [RFC3473], and the LABEL object MUST be bridge processing is per [RFC3473], and the LABEL object MUST be
passed on unchanged, upstream. The ESP-VID2/ESP-MAC2 tuple contained passed on unchanged, upstream. The ESP-VID2/ESP-MAC2 tuple contained
in the LABEL Object is installed in the forwarding table as a static 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 forwarding entry at each hop. This creates a bidirectional Eth-LSP as
the PATH and RESV messages follow the same path. the PATH and RESV messages follow the same path.
4.1.1. P2P Path Maintenance 4.1.1. P2P Path Maintenance
Make before break procedures can be employed to modify the Make before break procedures can be employed to modify the
characteristics of a P2P Eth LSP. As described in [RFC3209], the LSP 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 ID in the sender template is updated as the new path is signaled. The
procedures (including those for shared forwarding) are identical to procedures (including those for shared forwarding) are identical to
those employed in establishing a new LSP, with the extended tunnel ID those employed in establishing a new LSP, with the extended tunnel ID
in the signaling exchange ensuring that double booking of an in the signaling exchange ensuring that double booking of an
associated resource does not occur. associated resource does not occur.
Where individual paths in a protection group are modified, signaling Where individual paths in a protection group are modified, signaling
procedures MAY be combined with Protection Switching (PS) procedures MAY be combined with Protection Switching (PS)
coordination to administratively force PS switching operations such coordination to administratively force PS switching operations such
that modification is only ever performed on the protection path. that modification is only ever performed on the protection path. PS
is a native capability of PBB-TE [IEEE 802.1Qay] that can operate
when two paths are set up between two common end points.
4.2. P2MP Ethernet-LSPs 4.2. P2MP Ethernet-LSPs
PBB-TE supports P2MP VID/Multicast MAC (MMAC) forwarding. In this 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 case the PBB-TE Ethernet Label consists of a VID and a Group MAC
address. The procedures outlined in [RFC3473] and [RFC4875]could be address. The procedures outlined in [RFC3473] and [RFC4875]could be
adapted to signal P2MP LSPs for the source (point) to destination adapted to signal P2MP LSPs for the source (point) to destination
(multipoint) direction. Each one of the branches of the P2MP Eth-LSP (multipoint) direction. Each one of the branches of the P2MP Eth-LSP
would be associated with a reverse path symmetric and congruent P2P would be associated with a reverse path symmetric and congruent P2P
Eth-LSP. Eth-LSP.
skipping to change at page 13, line 8 skipping to change at page 12, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESP MAC | | ESP MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 PBB-TE Ethernet Label Figure 3 PBB-TE Ethernet Label
This format MUST be used for both P2P and P2MP Eth-LSPs. For P2P Eth- This format MUST be used for both P2P and P2MP Eth-LSPs. For P2P Eth-
LSPs the fields specify a VID and a unicast MAC address, while for 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. 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 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 passed unchanged at each hop. This has similarity to the way in which
a wavelength label is handled at an intermediate switch that cannot a wavelength label is handled at an intermediate bridge that cannot
perform wavelength conversion, and is described in [RFC3473]. perform wavelength conversion, and is described in [RFC3473].
4.4. Protection Paths 4.4. Protection Paths
When protection is used for path recovery it is required to associate When protection is used for path recovery it is required to associate
the working and protection paths into a protection group. This is the working and protection paths into a protection group. This is
achieved as defined in [RFC4872] and [RFC4873] using the ASSOCIATION achieved as defined in [RFC4872] and [RFC4873] using the ASSOCIATION
and PROTECTION objects. and PROTECTION objects.
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 bridges. 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] MAY be used to create the I-SID CALL signaling [RFC4974] MAY be used to create an association between
association between the endpoints prior to Eth-LSP establishment. the Eth-LSP endpoints prior to establishment of the LSP. The
Alternatively, the GMPLS RSVP-TE PATH messages can carry the I-SID CALL_ATTRIBUTES object can be used during CALL signaling as described
association at the time of Eth-LSP signaling. Therefore it is in [RFC4974] to indicate properties of the CALL. The Service ID TLV
possible to create I-SID association either when the path is set up defined below can be carried in the CALL_ATTRIBUTES object to
or at a later time. indicate the I-SID to ESP mapping for the Eth-LSP that will be set up
in association with the CALL.
Alternatively, the GMPLS RSVP-TE PATH message can carry the I-SID
association using the Service ID TLV in the LSP_ATTRIBUTES object
[RFC5420] at the time of Eth-LSP signaling. Using this mechanism, it
is possible to create the I-SID association either when the path is
set up or at a later time using a PATH refresh.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID Set 1 | | I-SID Set 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : : : :
: : : : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| I-SID Set n | | I-SID Set n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Service ID TLV Figure 4 Service ID TLV
- Flags: are used to control properties of service configuration. - Flags: are used to control properties of service configuration.
This document does not define flags. This document does not define flags.
- I-SID Set TLV(Type 1): is used to define a list or range of I- - 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 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 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 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 define a list or range of I-SIDs. The format of the I-SID Set TLV
is based on the LABEL_SET Object: is based on the LABEL_SET Object:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | | Action | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | I-SID 1 | | Reserved | I-SID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : : : : :
: : : : : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | I-SID n | | Reserved | I-SID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 I-SID Set TLV Figure 5 I-SID Set TLV
- Action: 8 bits - Action: 8 bits
The following actions are defined: list (0), range (1). The following actions are defined: list (0), range (1). When a
range is defined, there are only two I-SIDs that follow the
beginning I-SID and the end of the range I-SID. When list is
defined, a number of I-SIDs may be defined.
- I-SID: 24 bits - I-SID: 24 bits
The I-SID value identifies a particular backbone service The I-SID value identifies a particular backbone service
instance. instance.
5. Error conditions 5. Error conditions
The following errors identify Eth-LSP specific problems. The following errors identify Eth-LSP specific problems.
In PBB-TE a set of ESP-VIDs allocated to PBB-TE must be configured.
Therefore it is possible in some situations that the configuration of
a bridge is not the same as other bridges. If the ESP-VIDs of various
bridges have some ESP-VIDs in common it is possible some paths may be
set up before encountering issues. This is a management issue since
all bridges should have the same ESP-VID range. Configuration should
be consistent.
5.1. ESP-VID related errors 5.1. ESP-VID related errors
The network operator administratively selects a The network operator administratively selects a set of VLAN
set of VLAN Identifiers that can be used to setup ESPs. Identifiers that can be used to setup ESPs. Consequently, any VID
Consequently, any VID outside the allocated range is invalid and an outside the allocated range is invalid and an error MUST be generated
error MUST be generated where the mismatch is discovered. where the mismatch is discovered. The Error indication is carried in
the PathErr message from any intermediate bridge that does not
support the signaled source VID or optionally the destination VID.
The Error MAY be indicated in the ResvErr if the allocation error
happens on the RESV message. In this case a bridge that does not
support the signaled destination VID MUST signal the error.
5.1.1. Invalid ESP-VID value in the PBB-TE Ethernet Label 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 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 the Label object, for PBB-TE ESPs, it MUST immediately generate an
error: Routing problem (24) / Unacceptable label value (6). Handling error: Routing problem (24) / Unacceptable label value (6). Handling
of this error is according to [RFC3209]. of this error is according to [RFC3209].
Note, this error may be originated by any switch along the path. Note that an originating Bridge can reuse an ESP-VID with a different
source or destination B-MAC address. By allocating a number of B-
MACs and a number of ESP-VIDs a large number of PBB-TE connections
may be supported.
Note, this error may be originated by any bridge along the path.
5.1.2. Allocated ESP-VID range is exhausted 5.1.2. Allocated ESP-VID range is exhausted
The destination bridge after receiving the PATH message has to The destination bridge after receiving the PATH message has to
allocate a VID, which together with its MAC address will constitute allocate a VID, which together with its MAC address will constitute
the PBB-TE Ethernet Label. Depending on the size of the allocated the PBB-TE Ethernet Label. Depending on the size of the allocated
VLAN range and the number of Eth-LSPs terminated on a particular VLAN range and the number of Eth-LSPs terminated on a particular
bridge, it is possible that the available VIDs are exhausted and bridge, it is possible that the available VIDs are exhausted and
hence no PBB-TE Ethernet Label can be allocated. In this case the hence no PBB-TE Ethernet Label can be allocated. In this case the
destination bridge SHOULD generate a PathErr message with error code: destination bridge SHOULD generate a PathErr message with error code:
Routing problem (24) and error value: PBB-TE Ethernet Label VID Routing problem (24) and error value: MPLS Label allocation failure
allocation failure (35?) [the new error sub-code to be allocated by (9).
IANA]
5.2. Invalid MAC Address 5.2. Invalid MAC Address
IEEE defines a set of reserved MAC addresses that have special IEEE defines a set of reserved MAC addresses that have special
meaning, processing and follow specific forwarding rules. These meaning, processing and follow specific forwarding rules. These
addresses cannot be used for PBB-TE ESPs. In the case the PBB-TE 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 Ethernet Label refers to such a MAC address, a bridge encountering
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 GMPLS controlled Ethernet PBB-TE system assumes that users and
that UNI ports or in this case BEB Ethernet UNI Ports to the domain devices attached to UNIs may behave maliciously, negligently, or
are untrusted. Care is required to ensure untrusted access to the incorrectly. Intra-provider control traffic is trusted to not be
trusted domain does not occur. Where GMPLS is applied to the control malicious. In general, these requirements are no different from the
of VLAN only, the commonly known techniques for mitigation of security requirements for operating any GMPLS network. Access to the
Ethernet DOS attacks may be required on UNI ports. PBB-TE has been trusted network will only occur through the protocols defined for the
designed to interwork with legacy VLANs and the VLANs provide UNI or NNI or through protected management interfaces.
isolation from Ethernet legacy control planes.
When in-band GMPLS signaling is used for the control plane the
security of the control plane and the data plane may affect each
other. When out-of-band GMPLS signaling is used for the control
plane the data plane security is decoupled from the control plane and
therefore the security of the data plane has less impact on overall
security.
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.
For a more comprehensive discussion on GMPLS security please see the
Security Framework for MPLS and GMPLS Networks[RFC5920].
Cryptography can be used to protect against many attacks described in
[RFC5920]. One option for protecting "transport" Ethernet is the use
of 802.1AE Media Access Control Security, [MACSEC] which provides
encryption and authentication."
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
VID allocation failure" (suggested value: 35?) under the VID allocation failure" (suggested value: 35?) under the
"Routing problem" (24) error code in the RSVP Parameters / Error "Routing problem" (24) error code in the RSVP Parameters / Error
Codes and Globally-Defined Error Value Sub-Codes registry. Codes and Globally-Defined Error Value Sub-Codes registry.
skipping to change at page 17, line 14 skipping to change at page 17, line 46
[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.
[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)",
draft-ietf-ccamp-gmpls-mln-extensions, 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 [RFC5828] Fedyk, D. Berger, L., Andersson L., "GMPLS Ethernet Label
Switching Architecture and Framework", work in progress. Switching Architecture and Framework", RFC 5828, March 2010.
[IEEE 802.1ay] "IEEE Standard for Local and Metropolitan Area
[IEEE 802.1Qay] "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
Networks - Virtual Bridged Local Area Networks
- 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
[RFC4655] 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
skipping to change at page 18, line 11 skipping to change at page 18, line 43
[RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May [RFC4873] Berger, L. et.al.,"MPLS Segment Recovery", RFC 4873, May
2007. 2007.
[RFC3209] Awduche, D. et.al., "RSVP-TE: Extensions to RSVP for LSP [RFC3209] Awduche, D. et.al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels, IETF RFC 3209, December 2001. Tunnels, IETF RFC 3209, December 2001.
[RFC4974] Papadimitriou, D. and Farrel, A. "Generalized MPLS (GMPLS) [RFC4974] Papadimitriou, D. and Farrel, A. "Generalized MPLS (GMPLS)
RSVP-TE Signaling Extensions in Support of Calls", August 2007. RSVP-TE Signaling Extensions in Support of Calls", August 2007.
[Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM Functions [RFC5920] Fang, L. et.al.,"Security Framework for MPLS and GMPLS
and Mechanisms for Ethernet based Networks ", (2006). Networks", RFC 5920, July 2010.
[MACSEC] "IEEE Standard for Local and metropolitan area networks
Media Access Control (MAC) Security IEEE 802.1AE-2006",
August 18, 2006.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen
Shew, Dave Martin and Sandra Ballarte for their contributions to this Shew, Dave Martin and Sandra Ballarte for their contributions to this
document. document. The authors thank Deborah Brungard and Adrian Farrel for
their review and suggestions to this document.
10. Author's Address 10. Author's Address
Don Fedyk Don Fedyk
Alcatel-Lucent Alcatel-Lucent
Groton, MA, 01450 Groton, MA, 01450
Phone: +1-978-467-5645 Phone: +1-978-467-5645
Email: donald.fedyk@alcatel-lucent.com Email: donald.fedyk@alcatel-lucent.com
David Allan David Allan
skipping to change at line 785 skipping to change at line 836
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: Mon May 3 10:05:11 EDT 2010 Generated on: Wed Aug 18 15:53:56 EDT 2010
 End of changes. 46 change blocks. 
97 lines changed or deleted 148 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/