draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt   draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt 
Internet Draft Don Fedyk, Nortel
Category: Standards Track Himanshu Shah, Ciena
Expiration Date: January 14, 2009 Nabil Bitar, Verizon
Attila Takacs, Ericsson
Network Working Group Don Fedyk, David Allan, Nortel July 14, 2008
Internet Draft Himanshu Shah, Ciena
Category: Standards Track Nabil Bitar, Verizon
Attila Takacs, Diego Caviglia, Ericsson
Alan McGuire, BT
Nurit Sprecher, Nokia Siemens Networks
Lou Berger, LabN
April 14, 2008
GMPLS control of Ethernet GMPLS control of Ethernet PBB-TE
draft-ietf-ccamp-gmpls-ethernet-pbb-te-00.txt
draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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/ietf/1id-abstracts.txt. 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 in October 2008. This Internet-Draft will expire on January 14, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This memo is complementary to [ARCH] and describes how a GMPLS This specification is complementary to the GMPLS controlled Ethernet
control plane may be applied to the Provider Backbone Bridges Traffic architecture document [ARCH] and describes the technology specific
Engineering (PBB-TE) [IEEE 802.1Qay] amendment to 802.1Q and how aspects of GMPLS control for Provider Backbone Bridging Traffic
GMPLS can be used to configure VLAN-aware Ethernet switches in order Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary GMPLS extensions
to establish Ethernet point to point (P2P) and P2MP MAC switched and mechanisms are described to establish Ethernet PBB-TE point to
paths and P2P/P2MP VID based trees. This document supports, but does point (P2P) and point to multipoint (P2MP) connections. This document
not modify, the standard IEEE data. supports, but does not modify, the standard IEEE data plane.
Table of Contents
1 Introduction .............................................. 3
1.1 Co-authors ................................................ 3
2 Terminology ............................................... 4
2.1 PBB-TE Terminology ........................................ 5
3 Creation and Maintenance of PBB-TE Service Instances ...... 6
3.1 Ethernet Service .......................................... 7
3.2 Addresses, Interfaces, and Labels ......................... 7
4 Specific Procedures ....................................... 10
4.1 P2P connections ........................................... 10
4.1.1 Shared Forwarding ......................................... 11
4.1.2 P2P connections with shared forwarding .................... 12
4.1.3 Dynamic P2P symmetry with shared forwarding ............... 13
4.1.4 Planned P2P symmetry ...................................... 13
4.1.5 P2P Path Maintenance ...................................... 13
4.2 P2MP Signaling ............................................ 14
4.3 P2MP ESP-MAC DA Connections ............................... 14
4.3.1 Setup procedures .......................................... 14
4.3.2 Maintenance Procedures .................................... 14
4.4 Ethernet Label ............................................ 15
4.5 OAM MEP ID and MA ID synchronization ...................... 16
4.6 Protection Paths .......................................... 16
5 Error conditions .......................................... 17
5.1 Invalid ESP-VID value for PBB-TE MSTI range ............... 17
5.2 Invalid MAC Address ....................................... 17
5.3 Invalid ERO for UPSTREAM_LABEL Object ..................... 17
5.4 Invalid ERO for LABEL_SET Object .......................... 18
5.5 Switch is not ESP P2MP capable ............................ 18
5.6 Invalid ESP-VID in UPSTREAM_LABEL object .................. 18
6 Deployment Scenarios ...................................... 18
7 Security Considerations ................................... 18
8 IANA Considerations ....................................... 18
9 References ................................................ 19
9.1 Normative References ...................................... 19
9.2 Informative References .................................... 19
10 Acknowledgments ........................................... 21
11 Author's Address .......................................... 21
A. Rational and mechanism for PBB_TE Ethernet Forwarding ..... 22
A.1. Overview of configuration of VID/DMAC tuples .............. 25
A.2 Overview of configuration of VID port membership .......... 28
A.3 OAM Aspects ............................................... 28
A.4 QOS Aspects ............................................... 29
A.5 Resiliency Aspects ........................................ 29
A.5.1 E2E Path protection ....................................... 29
12 Full Copyright Statement .................................. 30
13 Intellectual Property ..................................... 30
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Document History
This document has under gone name changes to follow the
standardization of Provider Backbone Bridges and the Traffic
engineering capability.
draft-fedyk-gmpls-ethernet-ivl-00.txt.
This was the original draft.
draft-fedyk-gmpls-ethernet-pbt-00.txt
draft-fedyk-gmpls-ethernet-pbt-01.txt
This draft was renamed to reflect the Provider Backbone Transport
(PBT) nomenclature. Several co-authors joined the draft.
draft-fedyk-gmpls-ethernet-pbb-te-00.txt
The standardization of PBT is called Provider Backbone Bridges
Traffic Engineering (PBB-TE). The draft was aligned the PBB-TE
Technology.
draft-fedyk-gmpls-ethernet-pbb-te-01.txt
This is the second revision of the PBB-TE draft with editing to
clarify the document and the addition of co-authors.
draft-fedyk-gmpls-ethernet-pbb-te-02.txt
This is a third revision with the general aspects of Ethernet being
move to the architecture and framework [ARCH] and the specifics for
PBB-TE becoming more clear.
Table of Contents
1. Introduction...................................................4
2. Terminology....................................................4
2.1 PBB-TE Terminology...........................................5
3. GMPLS creation and maintenance of PBB-TE Service Instances.....5
3.1 Ethernet Service.............................................6
3.2 Addresses, Interfaces, and Labels............................7
4. Specific Procedures............................................9
4.1 P2P connections..............................................9
4.1.1 Shared Forwarding..........................................10
4.1.2 P2P connections with shared forwarding.....................11
4.1.3 Dynamic P2P symmetry with shared forwarding................12
4.1.4 Planned P2P symmetry.......................................12
4.1.5 P2P Path Maintenance.......................................12
4.2 P2MP Signaling..............................................13
4.3 P2MP VID/ESP-MAC DA Connections.............................13
4.3.1 Setup procedures...........................................13
4.3.2 Maintenance Procedures.....................................13
4.4 Ethernet Label..............................................14
4.5 OAM MEP ID and MA ID synchronization........................15
4.6 Protection Paths............................................15
5. Error conditions..............................................16
5.1 Invalid ESP-VID value for PBB-TE MSTI range.................16
5.2 Invalid MAC Address.........................................16
5.3 Invalid ERO for UPSTREAM_LABEL Object.......................16
5.4 Invalid ERO for LABEL_SET Object............................16
5.5 Switch is not ESP P2MP capable..............................16
5.6 Invalid ESP-VID in UPSTREAM_LABEL object....................16
6. Deployment Scenarios..........................................16
7. Security Considerations.......................................16
8. IANA Considerations...........................................17
9. References....................................................17
9.1 Normative References........................................17
9.2 Informative References......................................17
10. Author's Address............................................18
11. Intellectual Property Statement.............................19
12. Disclaimer of Validity......................................20
13. Copyright Statement.........................................20
14. Acknowledgments.............................................20
Appendix A.......................................................21
Rational and mechanism for PBB_TE Ethernet Forwarding............21
A 1. Overview of configuration of VID/DMAC tuples...............23
A 2. Overview of configuration of VID port membership...........26
A 3. OAM Aspects................................................26
A 4. QOS Aspects................................................27
A 5. Resiliency Aspects.........................................27
A 5.1. E2E Path protection......................................27
1. Introduction 1. Introduction
IEEE 802.1 is specifying Traffic Engineered Ethernet paths in the IEEE 802.1 is specifying Traffic Engineered Ethernet paths in the
Provider Backbone Bridged network (PBB-TE) [IEEE 802.1Qay] based on Provider Backbone Bridged network (PBB-TE) [IEEE 802.1Qay] based on
managed objects that can be separated from the Spanning Tree Control managed objects that can be separated from the Spanning Tree Control
Plane and statically configured or managed by a another control Plane and statically configured or managed by another control plane.
plane. These paths have minor changes to Ethernet data plane These paths have minor changes to Ethernet data plane specified in
specified in the IEEE. IEEE 802 termed these paths "PBB-TE service the IEEE. IEEE 802 termed these paths "PBB-TE service instances".
instances".
The purpose of this document is to specify extensions for a GMPLS Generalized MPLS (GMPLS) [RFC3945] is a family of control plane
based control plane to manage PBB-TE service instances. This draft protocols designed to operate in connection oriented and traffic
is aligned with GMPLS Ethernet Label Switching Architecture and engineering transport networks. GMPLS is applicable to a range of
Framework [ARCH]. 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 service instances. This
draft is aligned with the GMPLS Ethernet Label Switching Architecture
and Framework [ARCH].
It should be noted that due to the changes in the separation of the It should be noted that due to the changes in the separation of the
Spanning Tree Control plane and the PBB-TE forwarding, the behavior Spanning Tree Control plane and PBB-TE forwarding, the behavior of
of PBB-TE for the specified VLAN range is a new behavior. (It does PBB-TE for the specified VLAN range is a new behavior. (It does not
not default to conventional Ethernet forwarding with learning at any default to conventional Ethernet forwarding with learning at any
time). Appendix A summarized the rational for this data plane time). Note, currently PBB-TE is under specification in the
technology until the IEEE specification is more mature. Interworking Task Group of the IEEE 802.1 Working Group (WG), the
actual draft has version 3.5. Appendix A summarizes the rational for
this data plane technology until the IEEE specification is released
for Working Group Ballot in the IEEE 802.1 WG.
1.1. Co-authors
This document is the result the a large team of authors and
contributors. The following is a list of the co-authors:
Don Fedyk (Nortel)
David Allan (Nortel)
Himanshu Shah (Ciena)
Nabil Bitar (Verizon)
Attila Takacs (Ericsson)
Diego Caviglia (Ericsson)
Alan McGuire (BT)
Nurit Sprecher (Nokia Siemens Networks)
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 and introduces a few new terms: terminology from IEEE 802.1 and introduces a few new terms:
B-MAC Backbone MAC - BEB Backbone Edge Bridge
B-VID Backbone VLAN ID - B-MAC Backbone MAC
B-VLAN Backbone VLAN - B-VID Backbone VLAN ID
CBP Customer Backbone Port - B-VLAN Backbone VLAN
CCM Continuity Check Message - CBP Customer Backbone Port
COS Class of Service - CCM Continuity Check Message
CLI Command Line Interface - COS Class of Service
CIP Customer Instance Port - CLI Command Line Interface
C-MAC Customer MAC - CIP Customer Instance Port
C-VID Customer VLAN ID - C-MAC Customer MAC
C-VLAN Customer VLAN - C-VID Customer VLAN ID
DMAC Destination MAC Address - C-VLAN Customer VLAN
ESP Ethernet Switched Path - DMAC Destination MAC Address
Eth-LSP Ethernet Label switched Path - ESP Ethernet Switched Path
I-SID Ethernet Service Instance Identifier - Eth-LSP Ethernet Label Switched Path
LBM Loopback Message - I-SID Ethernet Service Instance Identifier
LBR Loopback Reply - LBM Loopback Message
LLDP Link Layer Discovery Protocol - LBR Loopback Reply
LMM Loss Measurement Message - LLDP Link Layer Discovery Protocol
LMR Loss Measurement Reply - LMM Loss Measurement Message
MAC Media Access Control - LMR Loss Measurement Reply
MMAC Multicast MAC - MAC Media Access Control
MSTI Multiple Spanning Tree Instance - MMAC Multicast MAC
MP2MP Multipoint to multipoint - MSTID Multiple Spanning Tree Identifier
PBB Provider Backbone Bridges - MP2MP Multipoint to multipoint
PBB-TE Provider Backbone Bridges Traffic Engineering - PBB Provider Backbone Bridges
PIP Provider Instance Port - PBB-TE Provider Backbone Bridges Traffic Engineering
PNP Provider Network Port - PIP Provider Instance Port
P2P Point to Point - PCP Priority Code Points
P2MP Point to Multipoint - PNP Provider Network Port
QOS Quality of Service - P2P Point to Point
ESP-MAC SA Source MAC Address - P2MP Point to Multipoint
S-VID Service VLAN ID - QOS Quality of Service
SVL Shared VLAN Learning - ESP-MAC SA Source MAC Address
VID VLAN ID - S-VID Service VLAN ID
VLAN Virtual LAN - SVL Shared VLAN Learning
- TE-MSTID Traffic Engineering MSTID
- VID VLAN ID
- VLAN Virtual LAN
2.1 PBB-TE Terminology 2.1. PBB-TE Terminology
The PBB-TE specification has defiend some additional termminology to The PBB-TE specification has defined some additional terminology to
clarify the PBB-TE functions. We repeat these here in expanded clarify the PBB-TE functions. We repeat these here in expanded
context to translate from IEEE to GMPLS terminology. context to translate from IEEE to GMPLS terminology.
- Ethernet Switched Path (ESP): A provisioned traffic engineered - Ethernet Switched Path (ESP):
unidirectional connectivity path between two or more Customer A provisioned traffic engineered unidirectional connectivity path
Backbone Ports(CBPs) which extends over a Provider Backbone Bridge between two or more Customer Backbone Ports (CBPs) which extends
Network (PBBN). The path is identified by the 3-tuple <ESP-MAC DA, over a Provider Backbone Bridge Network (PBBN). The path is
ESP-MAC SA, ESP-VID> where the ESP-VID value is allocated to the identified by the 3-tuple <ESP-MAC DA, ESP-MAC SA, ESP-VID> where
PBB-TE Multiple Spanning Tree Instance (MSTI)(A set of VIDs for the ESP-VID value is allocated to the PBB-TE Multiple Spanning
PBB-TE is allocated as a set of MSTIs). An ESP is analogous to an Tree Identifier (MSTID). (A set of VIDs for PBB-TE is allocated
GMPLS LSP. to the new TE-MSTID.) An ESP is analogous to a GMPLS LSP.
- PBB-TE Region: A set of PBB switches and PB switches by a set of
Service-VLANs allocated to provisioned Ethernet Switched Paths
(ESPs).
- PBB-TE service instance: A Point-to-Point or a Point-to-Multipoint
PBB-TE service instance.
- PBB-TE Trunk: A Point-to-Point PBB-TE service instance.
- Point-to-Point PBB-TE service instance: An instance of the MAC - Point-to-Point PBB-TE service instance:
service provided by two unidirectional co-routed ESPs forming a An instance of the MAC service provided by two unidirectional co-
bidirectional service. A GMPLS bidirectional path is analogous to routed ESPs forming a bidirectional service. A GMPLS
a P2P PBB-TE Service instance. bidirectional path is analogous to a P2P PBB-TE Service instance.
- Point-to-Multipoint PBB-TE service instance: An instance of the - Point-to-Multipoint PBB-TE service instance:
MAC service provided by a set of ESPs which comprises one An instance of the MAC service provided by a set of ESPs which
multipoint ESP plus n unidirectional point-to-point ESPs, routed comprises one point-to-multipoint ESP plus n unidirectional
along the leaves of the multicast ESP. A P2MP GMPLS bidirectional point-to-point ESPs. The n P2P ESPs are co-routed but in the
tree is analogous to a P2MP PBB-TE service instance. opposite direction from the root-to-leaf sub-ESPs comprising the
P2MP ESP. Note that due to traditional Ethernet data plane
design this definition is different to the way P2MP connections
are generally defined. That is, while P2MP connections are
generally root-to-leaves unidirectional trees, P2MP PBB-TE
services can be regarded as bidirectional trees.
3. GMPLS creation and maintenance of PBB-TE Service Instances 3. Creation and Maintenance of PBB-TE Service Instances
PBB-TE is an Ethernet connection oriented technology, being PBB-TE is an Ethernet connection oriented technology, being specified
specified in the IEEE, which can be controlled by configuration of in the IEEE, which can be controlled by configuration of static
static filtering entries [see Appendix A] for some details on the filtering entries (see Appendix A for some details on the rational
rational for the data plane. PBB-TE ESPs are created switch by for the data plane). PBB-TE ESPs are created switch by switch by
switch by simple configuration of Ethernet logical ports and simple configuration of Ethernet logical ports and assignment of PBB-
assignment of PBB-TE labels or by a control plane. This document TE labels or by a control plane. This document describes GMPLS as a
describes GMPLS as a valid control plane for Eth-LSPs that are based valid control plane for Eth-LSPs that are based on PBB-TE ESPs. A
on PBB-TE ESPs. A Point-to-Point PBB-TE service instance is a form Point-to-Point PBB-TE service instance is a form of Ethernet LSP
of Ethernet LSP (Eth-LSP) which is more broadly defined in [ARCH]. (Eth-LSP) which is more broadly defined in [ARCH]. This memo
This memo describes GMPLS as a mechanism to automate set-up describes GMPLS as a mechanism to automate set-up teardown,
teardown, protection and recovery of PBB-TE ESPs and specifies the protection and recovery of PBB-TE ESPs and specifies the specific
specific TLVs for control of PBB-TE service instances. TLVs for control of PBB-TE service instances.
When configuring a PBB-TE ESP with GMPLS, the ESP-MAC DA and ESP-VID When configuring a PBB-TE ESP with GMPLS, the ESP-MAC DA and ESP-VID
are carried in a generalized label object and are assigned hop by are carried in a generalized label object and are assigned hop by hop
hop but are invariant within a domain. This invariance is similar to but are invariant within a domain. This invariance is similar to
GMPLS operation in transparent optical networks. As is typical with GMPLS operation in transparent optical networks. As is typical with
other technologies controlled by GMPLS, the data plane receiver must other technologies controlled by GMPLS, the data plane receiver must
accept, and usually assigns, labels from its available label pool. accept, and usually assigns, labels from its available label pool.
This, together with the label invariance requirement mentioned This, together with the label invariance requirement mentioned above,
above, result in each PBB-TE label being a domain wide unique label, result in each PBB-TE label being a domain wide unique label, with a
with a unique ESP-VID + ESP-MAC DA, for each direction. unique ESP-VID + ESP-MAC DA, for each direction.
The following illustrates the identifiers for Labels and ESPs. The following illustrates the identifiers for Labels and ESPs.
GMPLS Upstream Label <ESP:MAC1(DA), VID1> (60 bits) GMPLS Upstream Label <ESP:MAC1(DA), VID1> (60 bits)
GMPLS Downstream Label <ESP:MAC2(DA), VID2> (60 bits) GMPLS Downstream Label <ESP:MAC2(DA), VID2> (60 bits)
Upstream PBB-TE ESP 3-tuple <ESP:MAC1, MAC2, VID1> (108 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) Downstream PBB-TE ESP 3-tuple <ESP:MAC2, MAC1, VID2> (108 bits)
Table 1 Labels and ESPs Table 1 Labels and ESPs
The MAC is domain wide unique in the network. PBB-TE defines the The MAC is domain wide unique in the network. PBB-TE defines the
tuple of <ESP-MAC DA, ESP-MAC SA, ESP-VID> as a unique connection 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 identifier in the data plane but the forwarding operation only uses
the ESP-MAC DA (DMAC) and the ESP-VID in each direction. Note that the ESP-MAC DA (DMAC) and the ESP-VID in each direction. Note that
the MAC addresses for PBB-TE are part of the Backbone Component the MAC addresses for PBB-TE are part of the Backbone Component
Relay (B-Component) and are associated with Provider addresses Relay (B-Component) and are associated with Provider addresses
corresponding to the Backbone Customer ports as described in section corresponding to the Customer Backbone ports (CBP) of the Backbone
3.2. The ESP-VID (VID) typically comes from a small number of VIDs Component (B-Component) as described in section 3.2.
dedicated to PBB-TE MSTI. The ESP-VID (VID) can be reused across The ESP-VID (VID) typically comes from a small number of VIDs
ESPs. There is no requirement the ESP-VID for two ESPs that for a dedicated to PBB-TE MSTID. The ESP-VID (VID) can be reused across
ESPs. There is no requirement the ESP-VID for two ESPs that form a
PBB-TE Service instance be the same. PBB-TE Service instance be the same.
Several attributes may be associated with an Eth-LSP. These are Several attributes may be associated with an Eth-LSP. These are
reviewed in Section 3 of [ARCH]. Several other aspects of GMPLS reviewed in Section 3 of [ARCH]. Several other aspects of GMPLS
covered by [ARCH] also apply equally to PBB-TE. This includes the covered by [ARCH] also apply equally to PBB-TE. This includes the
GMPLS routing and addressing model, link management, path GMPLS routing and addressing model, link management, path
computation and selection, and multiple domains. computation and selection, and multiple domains.
3.1 Ethernet Service 3.1. Ethernet Service
Ethernet Switched Paths that are setup either by configuration or Ethernet Switched Paths that are setup either by configuration or
signaling can be used to provide an Ethernet service to customers of signaling can be used to provide an Ethernet service to customers of
the Ethernet network. The Metro Ethernet Forum has defined some the Ethernet network. The Metro Ethernet Forum has defined some
services in [MEF.6] (e.g., Ethernet Private Line), and these are also services in [MEF.6] (e.g., Ethernet Private Line), and these are also
aligned with ITU-T G.8011-x Recommendations. Of particular interest aligned with ITU-T G.8011-x Recommendations. Of particular interest
are the bandwidth profile parameters in [MEF.10] and whose associated are the bandwidth profile parameters in [MEF.10] and whose associated
bandwidth profile algorithm are based on [RFC4115] [RFC3270]. bandwidth profile algorithm are based on [RFC4115] [RFC3270].
Consideration should be given to supporting these in any signaling Consideration should be given to supporting these in any signaling
extensions for Ethernet LSPs. This will be addressed in a future extensions for Ethernet LSPs. This will be addressed in a future
version of this specification. version of this specification.
3.2 Addresses, Interfaces, and Labels 3.2. Addresses, Interfaces, and Labels
This specification uses an addressing scheme and a label space for This specification uses an addressing scheme and a label space for
the ingress/egress connection; the hierarchical TE Router the ingress/egress connection; the hierarchical TE Router
ID/Interface ID and the Ethernet ESP-VID/ESP-MAC DA tuple or ESP- ID/Interface ID and the Ethernet ESP-VID/ESP-MAC DA tuple or ESP-
VID/Multicast MAC as a label space. This draft is intended to be VID/Multicast MAC as a label space. This draft is intended to be
consistent with GMPLS addressing and Routing [ARCH]. consistent with GMPLS addressing and Routing [ARCH].
PBB-TE is defined for a PBB IB-Bridge. This is illustrated in Figure PBB-TE is defined for a PBB Network. As with PBB services, PBB-TE is
1. The Ethernet service is attached to a Customer Instance Port typically implemented in the Service and Backbone components of an
(CIP) of the Backbone Service Instance (I-component) Relay. The CIP IB-Backbone Edge Bridge (BEB). This is illustrated in Figure 1. The
is interfaced to a Virtual instance port (VIP) which is identified Ethernet service is attached to a Customer Instance Port (CIP) of the
with a configured service instance (I-SID) and attached to a Provider Backbone Service Instance (I-component) Relay. The CIP is connected
Instance Port (PIP). The PIP is configured to be attached to a via the I-Component Relay to a Virtual instance port (VIP) which is
customer Backbone port (CBP). (A point to point service instance is identified with a configured service instance (I-SID) and attached to
illustrated. A point to multipoint service could allow more than one a Provider Instance Port (PIP). The PIP is configured to be attached
CBP to be attached to a single PIP.) The CBP has a BMAC that defines to a customer Backbone port (CBP). (A point to point service instance
the MAC for the PBB-TE Service Instance. The B-Component relay adds is illustrated. A point to multipoint service could allow more than
the ESP Header the ESP-MAC DA, ESP-MAC SA and the ESP-VID. GMPLS is one CBP to be attached to a single PIP.) The CBP has a B-MAC that
being defined here to connect CPB MACs to signal the PBB-TE service defines the MAC for the PBB-TE Service Instance. That source B-MAC
Instance before the association of ESP-MAC DA and ESP-MAC SA is address is the PIP MAC address which in the case of backbone service
defined. instances that are supported by TE service instances is configured to
take the same value as the CBP B-MAC of the internally connected CBP
on the B-component. As a result, the backbone MAC addresses of
frames associated with traffic engineered services, the ESP-MACs, are
always equal to the CBP B-MAC. The I-Component PIP adds the ESP-MAC
DA and the ESP-MAC SA. The B-Component CBP adds the ESP-VID. GMPLS
is being defined here to connect CBP MACs to signal the PBB-TE
service Instance before the association of ESP-MAC DA and ESP-MAC SA
is defined.
The diagram also shows the addition of a TE Router ID to the PBB The diagram also shows the addition of a TE Router ID to the PBB
switch and the TE Link identifier to enable GMPLS. TE Links are not switch and the TE Link identifier to enable GMPLS. TE Links are not
associated with CPBs. TE Links are associated with PNPs. TE links are associated with CBPs. TE Links are associated with PNPs. TE links are
associated with node identifiers of backbone edge bridges (BEB) and associated with bridge identifiers of backbone edge bridges (BEB) and
backbone core bridges (BCB). CBPs are also associated with these node backbone core bridges (BCB). CBPs are also associated with these
ids. For GMPLS the node IDs are expressed as IP addresses as TE- bridge ids. For GMPLS the bridge IDs are expressed as IP addresses
Router IDs. [ADDRESS] as TE- Router IDs. [RFC4990]
Backbone Edge Bridge (BEB) Backbone Edge Bridge (BEB)
+------------------------------------------------------+ +------------------------------------------------------+
| <TE - Router ID > | | <TE - Router ID > |
| | | |
| I-Component Relay B-Component Relay | | I-Component Relay B-Component Relay |
| +-----------------------+ +---------------------+ | | +-----------------------+ +---------------------+ |
| | +---+ | | B-VID | | | | +---+ | | B-VID | |
| | |VIP| | | +---+ +---+ | | <TE Link> | | |VIP| | | +---+ +---+ | | <TE Link>
| | +---+ | +---|CBP| |PNP|------ | | +---+ | +---|CBP| |PNP|------
| | | | | +---+ +---+ | | | | | | | +---+ +---+ | |
| | +---+ +---+ | | | | | | | +---+ +---+ | | | | |
------|CIP| |PIP|----+ | | | ------|CIP| |PIP|----+ | | |
| | +---+ +---+ | | | | | | +---+ +---+ | | | |
| +-----------------------+ +---------------------+ | | +-----------------------+ +---------------------+ |
| | | |
| PBB Edge Bridge | | PBB Edge Bridge |
+------------------------------------------------------+ +------------------------------------------------------+
^--------Configured--------------^ ^--------Configured--------------^
^-GMPLS or Configured-. ^-GMPLS or Configured-^
Figure 2 Ethernet/GMPLS Addressing & Label Space Figure 2 Ethernet/GMPLS Addressing & Label Space
TE Router ID TE Router ID TE Router ID TE Router ID
| (TE Link) | | (TE Link) |
V | V N=named port V | V N=named port
+----+ | +-----+ <port index> +----+ | +-----+ <port index>
| | | label=ESP:VID/MAC DA | | <MAC> | | | label=ESP:VID/MAC DA | | <MAC>
| PB | V label=ESP:VID/MMAC | | <string> | PB | V label=ESP:VID/MMAC | | <string>
-----N N----------------------------N PBB N---------- -----N N----------------------------N PBB N----------
| | |(MAC)| \ | | |(MAC)| \
| | / | Customer | | / | Customer
+----+ /+-----+ Facing +----+ /+-----+ Facing
skipping to change at page 8, line 44 skipping to change at page 9, line 21
| | |(MAC)| \ | | |(MAC)| \
| | / | Customer | | / | Customer
+----+ /+-----+ Facing +----+ /+-----+ Facing
BCB ESP:MAC BEB Ports BCB ESP:MAC BEB Ports
Figure 3 Ethernet/GMPLS Addressing & Label Space Figure 3 Ethernet/GMPLS Addressing & Label Space
For a GMPLS based system, the TE Router ID/logical port is the For a GMPLS based system, the TE Router ID/logical port is the
logical signaling identifier for the control plane via which Ethernet logical signaling identifier for the control plane via which Ethernet
layer label bindings are solicited. In order to create a P2P path an layer label bindings are solicited. In order to create a P2P path an
association must be made between the ingress and egress node. The association must be made between the ingress and egress switch. The
actual label distributed via signaling and instantiated in the switch actual label distributed via signaling and instantiated in the switch
forwarding tables identifies the upstream and downstream egress ESP- forwarding tables identifies the upstream and downstream egress ESP-
VID/ESP-MAC DA of the PBB-TE ESP (see Figure 4). VID/ESP-MAC DA of the PBB-TE ESP (see Figure 3).
GMPLS uses identifiers in the form of 32 bit numbers which are in the GMPLS uses identifiers in the form of 32 bit numbers which are in the
IP address notation which may or may not be IP addresses. The IP address notation which may or may not be IP addresses. The
provider MAC port addresses are exchanged by the LLDP [IEEE 802.1AB] provider MAC port addresses are exchanged by the LLDP [IEEE 802.1AB]
and by LMP [RFC4204] if supported. However these identifiers are and by LMP [RFC4204] if supported. However these identifiers are
merely for link control and legacy Ethernet support and have local merely for link control and legacy Ethernet support and have local
link scope. Actual label assignment is performed by the ingress and link scope. Actual label assignment is performed by the ingress and
egress nodes using CPB MAC addresses. egress switches using CBP MAC addresses.
A particular PNP would have: A particular PNP would have:
- A VID/MAC - A VID/MAC
- An IP address, which is typically the TE router ID, plus a 32 bit - An IP address, which is typically the TE router ID, plus a 32 bit
interface Identifier also call an unnumbered link. interface Identifier also call an unnumbered link.
- One (or more) Mnemonic String Identifiers - One (or more) Mnemonic String Identifiers
This multiple naming convention leaves the issue of resolving the set This multiple naming convention leaves the issue of resolving the set
given one of the port identifiers. On a particular node, mapping is given one of the port identifiers. On a particular switch, mapping is
relatively straightforward. Per [ARCH], standard GMPLS mechanisms relatively straightforward. Per [ARCH], standard GMPLS mechanisms
are used for signaling resolution. In so doing, the problem of are used for signaling resolution. In so doing, the problem of
setting up a path is reduced to figuring out what switch supports an setting up a path is reduced to figuring out what switch supports an
egress CBP MAC address and then finding the corresponding egress IP egress CBP MAC address and then finding the corresponding egress IP
address and performing all signaling and routing with respect to the address and performing all signaling and routing with respect to the
egress. egress.
There are several options to achieve this: There are several options to achieve this:
- Provisioning
- Auto discovery protocols that carry MAC address - Provisioning - Auto discovery protocols that carry MAC address
- Augmenting Routing TE with MAC Addresses - Augmenting Routing TE with MAC Addresses
- Name Servers with identifier/address registration - Name Servers with identifier/address registration
The specific procedures will be clarified in a subsequent version of The specific procedures will be clarified in a subsequent version
this document. of this document.
4. Specific Procedures 4. Specific Procedures
4.1 P2P connections 4.1. P2P connections
The PBB-TE Service Instance is defined by the ESP 3-tuples for each The PBB-TE Service Instance is defined by the ESP 3-tuples for each
of the unidirectional ESPs. From a GMPLS control plane point of view of the unidirectional ESPs. From a GMPLS control plane point of view
an Ethernet LSP MAY also be identified as any other LSP using the 5- an Ethernet LSP is also identified as any other LSP using the 5-
tuple [Ip_Source_Sddr, Ip_Dest_Addr, LSP_Id, Tunnel_ID, tuple [Ip_Source_Sddr, Ip_Dest_Addr, LSP_Id, Tunnel_ID,
Extended_Tunnel_ID]. The ESP-VID and ESP-MAC DA tuple identifies the Extended_Tunnel_ID]. The ESP-VID and ESP-MAC DA tuple identifies the
forwarding multiplex at transit switches and a simple degenerate form forwarding multiplex at transit switches and a simple degenerate form
of the multiplex is a single P2P connection. of the multiplex is a single P2P connection.
This results in unique labels end to end. The data streams MAY merge, This results in unique labels end to end. The data streams MAY merge,
the forwarding entries MAY be shared but the headers are still unique the forwarding entries MAY be shared but the headers are still unique
allowing the connection to be de-multiplexed downstream. allowing the connection to be de-multiplexed downstream. Note that
in addition to the ESP 3-tuples the I-SID in the I-TAG also provides
for unambiguous identification of frames belonging to a certain
service. This adds further protection against misconfiguration and
misconnectivity errors, by allowing simple detection and immediate
squelching of unintended traffic.
On the initiating and terminating nodes, a function administers the On the initiating and terminating switches, a function administers
ESP-VIDs associated with the ESP-MAC SA and ESP-MAC DA respectively. the ESP-VIDs associated with the ESP-MAC SA and ESP-MAC DA
PBB-TE is designed to be bidirectional and symmetrically routed just respectively. PBB-TE is designed to be bidirectional and
like Ethernet. Therefore in PBB-TE, the packet ESP-MAC SA and ESP- symmetrically routed just like Ethernet. Therefore in PBB-TE, the
MAC DA pair is same in the forwarding path and the associated packet ESP-MAC SA and ESP- MAC DA pair is same in the forwarding path
reverse path except they are flipped in the reverse direction. and the associated reverse path except they are flipped in the
reverse direction.
To initiate a bidirectional ESP-VID/ESP-MAC DA P2P or P2MP path, the To initiate a bidirectional ESP-VID/ESP-MAC DA P2P or P2MP path, the
initiator of the PATH message uses procedures outlined in [RFC3473] initiator of the PATH message uses procedures outlined in [RFC3473]
possibly augmented with [RFC4875], it: possibly augmented with [RFC4875], it:
1) Sets the LSP encoding type to Ethernet. 1) Sets the LSP encoding type to Ethernet.
2) Sets the LSP switching type to 802_1 PBB-TE [IANA to define]. 2) Sets the LSP switching type to 802_1 PBB-TE [IANA to define].
3) Sets the GPID to service type [IANA to define]. 3) Sets the GPID to service type [IANA to define].
4) Sets the UPSTREAM_LABEL to the ESP-VID/ESP-MAC SA tuple where the 4) Sets the UPSTREAM_LABEL to the ESP-VID/ESP-MAC SA tuple where the
ESP-VID is administered from the configured ESP-VID/ESP-MAC DA ESP-VID is administered from the configured ESP-VID/ESP-MAC DA range.
range.
5) Optionally sets the LABEL_SET or SUGGESTED_LABEL if it chooses to 5) Optionally sets 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) Optionally look at Call / Connection ID for Carrying I-SID. 6) Optionally look at Call / Connection ID for Carrying I-SID.
Intermediate and egress node processing is not modified by this Intermediate and egress switch processing is not modified by this
document, i.e., is per [RFC3473] and, in the case of P2MP, as document, i.e., is per [RFC3473] and, in the case of P2MP, as
extended in [RFC4875]. Note, as previously stated intermediate nodes extended in [RFC4875]. Note, as previously stated intermediate
supporting the 802_1 switching type may not modify LABEL values. bridges supporting the 802_1 switching type may not modify LABEL
values.
The ESP-VID/ESP-MAC SA tuple contained in the UPSTREAM_LABEL is used The ESP-VID/ESP-MAC SA tuple contained in the UPSTREAM_LABEL is 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 [IANA to define]. inferred from the switching type which is 802_1 [IANA to define].
The port derived from the RSVP_HOP object and the ESP-VID and ESP- The port derived from the RSVP_HOP object and the ESP-VID and ESP-
MAC DA included in the label constitute the static entry. MAC DA included in the label constitute the static entry.
At the destination, a ESP-VID is allocated in the local MAC range At the destination, a ESP-VID is allocated in the local MAC range for
for the ESP-MAC DA and the ESP-VID/ESP-MAC DA tuple is passed in a the ESP-MAC DA and the ESP-VID/ESP-MAC DA tuple is passed in a LABEL
LABEL object in the RESV message. As with the Path message, object in the RESV message. As with the PATH message, intermediate
intermediate node processing is per [RFC3473] and [RFC4875], and the switch processing is per [RFC3473] and [RFC4875], and the LABEL
LABEL object is passed on unchanged, upstream. The ESP-VID/ESP-MAC object is passed on unchanged, upstream. The ESP-VID/ESP-MAC DA
DA tuple contained in the LABEL Object is installed in the tuple contained in the LABEL Object is installed in the forwarding
forwarding table as a static forwarding entry at each hop. This table as a static forwarding entry at each hop. This creates a
creates a bidirectional path as the PATH and RESV messages follow bidirectional path as the PATH and RESV messages follow the same
the same path. path.
4.1.1 Shared Forwarding 4.1.1. Shared Forwarding
One capability of a connectionless Ethernet data plane is to reuse One capability of a connectionless Ethernet data plane is to reuse
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. Shared forwarding has no impact on the allocation at each end. Shared forwarding has no impact on the actual
actual paths setup, but it allows the reduction of forwarding paths setup, but it allows the reduction of forwarding entries.
entries. Shared forwarding paths are identical to independently Shared forwarding paths are identical to independently routed paths
routed paths with the exception that they share the same labels and with the exception that they share the same labels and same path from
same path from the merge point. the merge point.
To achieve shared forwarding, a Path computation engine [PATHCOMP] To achieve shared forwarding, a Path computation engine [PATHCOMP]
should ensure the ERO is consistent with an existing path for the should ensure the ERO is consistent with an existing path for the
shared segments. If a path satisfies the consistency check, the shared segments. If a path satisfies the consistency check, the
upstream end of the signaling may chose to share an existing ESP- upstream end of the signaling may chose to share an existing ESP-
VID/ESP-MAC DA for the upstream traffic with an existing Eth-LSP. VID/ESP-MAC DA for the upstream traffic with an existing Eth-LSP.
The criteria for shared forwarding is the Eth-LSPs must share the The criteria for shared forwarding is the Eth-LSPs must share the
same destination port and the paths of the Eth-LSP share one or more same destination port and the paths of the Eth-LSP share one or more
hops consecutively. Once the paths converge they must remain hops consecutively. Once the paths converge they must remain
converged. If no existing path has this behavior when a new path is converged. If no existing path has this behavior when a new path is
being created, the new path will be created without sharing either being created, the new path will be created without sharing either by
by using another ESP-VID or another ESP-MAC DA or both. using another ESP-VID or another ESP-MAC DA or both.
In other words, shared forwarding is possible when paths share In other words, shared forwarding is possible when paths share
segments either from the source or the destination. There is no segments either from the source or the destination. There is no
requirement that the paths share reservations or other attributes. requirement that the paths share reservations or other attributes.
For the source, the UPSTREAM_LABEL is chosen to be the same as an For the source, the UPSTREAM_LABEL is chosen to be the same as an
existing path that shares the ERO for some number of hops. existing path that shares the ERO for some number of hops. Similarly
Similarly for the destination, shared forwarding is possible when an for the destination, shared forwarding is possible when an existing
existing path that shares segments with the new paths ERO, viewed path that shares segments with the new paths ERO, viewed from the
from the destination switch. The downstream label in this case is destination switch. The downstream label in this case is chosen to
chosen to be the same as the existing path. In this manner shared be the same as the existing path. In this manner shared forwarding is
forwarding is a function that is controlled primarily by policy and a function that is controlled primarily by policy and in combination
in combination with the local label allocation at the end points of with the local label allocation at the end points of the path.
the path.
4.1.2 P2P connections with shared forwarding 4.1.2. P2P connections with shared forwarding
The ESP-VID/ESP-MAC DA MAY be considered to be a shared forwarding The ESP-VID/ESP-MAC DA MAY be considered to be a shared forwarding
identifier or label for a multiplex consisting of some number of P2P identifier or label for a multiplex consisting of some number of P2P
connections distinctly identified by the MAC ESP-VID/ESP-MAC DA/ESP- connections distinctly identified by the MAC ESP-VID/ESP-MAC DA/ESP-
MAC SA tuple. In some ways this is analogous to an LDP label merge MAC SA tuple. In some ways this is analogous to an LDP label merge
but in the shared forwarding case only the forwarding entry is but in the shared forwarding case only the forwarding entry is
reused. Resources can continue to be allocated per LSP. reused. Resources can continue to be allocated per LSP.
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 node. decoupled from the actual steering of the packet at any given switch.
A switch terminating an Eth-LSP will frequently have more than one A switch terminating an Eth-LSP will frequently have more than one
suitable candidate path and it may choose to share a forwarding entry suitable candidate path and it may choose to share a forwarding entry
(common ESP-VID/ESP-MAC DA, unique ESP-MAC SA). It is a local (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 decision of how this is performed but the best choice is a path that
maximizes the shared forwarding. maximizes the shared forwarding.
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. As an example consider a PBB-TE edge switch that
terminates an Ethernet LSP with the following attributes: bandwidth 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 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, additional Ethernet LSP with attributes (bandwidth B2, ESP-MAC DA D,
ESP-MAC SA S2, ESP-VID V) can be accepted provided there is ESP-MAC SA S2, ESP-VID V) can be accepted provided there is
sufficient link capacity remaining. sufficient link capacity remaining.
skipping to change at page 12, line 15 skipping to change at page 13, line 10
maximizes the shared forwarding. maximizes the shared forwarding.
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. As an example consider a PBB-TE edge switch that
terminates an Ethernet LSP with the following attributes: bandwidth 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 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, additional Ethernet LSP with attributes (bandwidth B2, ESP-MAC DA D,
ESP-MAC SA S2, ESP-VID V) can be accepted provided there is ESP-MAC SA S2, ESP-VID V) can be accepted provided there is
sufficient link capacity remaining. sufficient link capacity remaining.
4.1.3 Dynamic P2P symmetry with shared forwarding 4.1.3. Dynamic P2P symmetry with shared forwarding
Similar to how a destination switch MAY select a ESP-VID/ESP-MAC DA Similar to how a destination switch MAY select a ESP-VID/ESP-MAC DA
from the set of existing shared forwarding multiplexes rooted at the from the set of existing shared forwarding multiplexes rooted at the
destination node, the originating switch MAY also do so for the destination switch, the originating switch MAY also do so for the
reverse path. Once the initial ERO has been computed and the set of reverse path. Once the initial ERO has been computed and the set of
existing Ethernet LSPs that include the target ESP-MAC DA have been existing Ethernet LSPs that include the target ESP-MAC DA have been
pruned, the originating switch may select the optimal (by whatever pruned, the originating switch may select the optimal (by whatever
criteria) existing shared forwarding multiplex for the new criteria) existing shared forwarding multiplex for the new
destination to merge with and offer its own ESP-VID/ESP-MAC DA tuple destination to merge with and offer its own ESP-VID/ESP-MAC DA tuple
for itself as a destination. for itself as a destination.
4.1.4 Planned P2P symmetry 4.1.4. Planned P2P symmetry
Normally the originating switch will not have knowledge of the set of Normally the originating switch will not have knowledge of the set of
shared forwarding paths rooted on the destination node. shared forwarding paths rooted on the destination switch.
Use of a Path Computation Server [PATHCOMP] or other planning style Use of a Path Computation Server [PATHCOMP] or other planning style
of tool with more complete knowledge of the network configuration may of tool with more complete knowledge of the network configuration may
wish to impose pre-selection of shared forwarding multiplexes to use wish to impose pre-selection of shared forwarding multiplexes to use
for both directions. In this scenario the originating switch uses the for both directions. In this scenario the originating switch uses
LABEL_SET and UPSTREAM_LABEL objects to indicate complete selection the LABEL_SET and UPSTREAM_LABEL objects to indicate complete
of the shared forwarding multiplexes at both ends. This may also selection of the shared forwarding multiplexes at both ends. This may
result in the establishment of a new ESP-VID/ESP-MAC DA path as the also result in the establishment of a new ESP-VID/ESP-MAC DA path as
LABEL_SET object may legitimately refer to a path that does not yet the LABEL_SET object may legitimately refer to a path that does not
exist. yet exist.
4.1.5 P2P Path Maintenance 4.1.5. 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 Ethernet LSP. As described in [RFC3209], characteristics of a P2P Ethernet LSP. As described in [RFC3209], the
the LSP ID in the sender template is updated as the new path is LSP ID in the sender template is updated as the new path is signaled.
signaled. The procedures (including those for shared forwarding) are The procedures (including those for shared forwarding) are identical
identical to those employed in establishing a new LSP, with the to those employed in establishing a new LSP, with the extended tunnel
extended tunnel ID in the signaling exchange ensuring that double ID in the signaling exchange ensuring that double booking of the
booking of the associated resources does not occur. associated resources 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 modifications are only ever performed on the protection path. that modifications are only ever performed on the protection path.
4.2 P2MP Signaling 4.2. P2MP Signaling
Note specifics for P2MP paths are being defined. This section will Note specifics for P2MP paths are being defined. This section will be
be updated to align with the PBB-TE specification [IEEE 802.1Qay]. updated to align with the PBB-TE specification [IEEE 802.1Qay].
To initiate a P2MP VID/Multicast MAC (MMAC) path the initiator of To initiate a P2MP VID/Multicast MAC (MMAC) path the initiator of the
the PATH message uses procedures outlined in [RFC3473] and PATH message uses procedures outlined in [RFC3473] and [RFC4875]. A
[RFC4875]. A P2MP tree consists of a VID tree or MMAC tree in the P2MP tree consists of a VID tree forward direction (from root to
forward direction (from root to leaves) and a set of P2P paths leaves) and a set of P2P paths running on identical paths from Tree
running on identical paths from Tree to root in the reverse leaves to root in the reverse direction. The result is a composite
direction. The result is a composite path with Multicast VID/ESP- path with a ESP- MMAC DA label with a single ESP-MMAC DA in the
MMAC DA labels with a single ESP-MMAC DA in the forward direction forward direction and a symmetric set of unidirectional ESP-VID/ESP-
and a symmetric unidirectional ESP-VID/ESP-MAC DA label in the MAC DA labels in the reverse direction:
reverse direction:
1-4) Same points as P2P paths previously specified. 1-4) Same points as P2P paths previously specified.
5) Sets the downstream label as the Multicast VID/ESP-MMAC DA. 5) Sets the downstream label as the ESP-MMAC DA.
6) VID translation may optionally be permitted on a local basis
between two switches by a downstream switch replying with a
Multicast VID/ESP-MMAC DA other than the LABEL_SET. The upstream
switch then sets a VID translation on the port associated with the
label to allow VID translation. This flexibility allows the tree to
be constructed with out having to worry about colliding with another
tree using the same VID. (Inclusion of this point is TBD by [IEEE
802.1Qay])
4.3 P2MP VID/ESP-MAC DA Connections 4.3. P2MP ESP-MAC DA Connections
4.3.1 Setup procedures 4.3.1. Setup procedures
The group ESP-MMAC DA is administered from a central pool of The group ESP-MMAC DA is administered from a central pool of
multicast addresses and the VLAN selected from the PBB-TE MSTI range. multicast addresses and the VLAN selected from the PBB-TE VID range.
The P2MP tree is constructed via incremental addition of leaves to The P2MP tree is constructed via incremental addition of leaves to
the tree in signaling exchange where the root is the originating the tree in signaling exchanges where the root is the originating
switch (as per (RFC4875). The multicast VID/ESP-MAC DA is encoded in switch (as per (RFC4875). The multicast VID/ESP-MMAC DA is encoded in
the LABEL_SET (as a member of one) object using the Ethernet label the LABEL_SET (as a member of one) object using the Ethernet label
encoding. encoding.
Where a return path is required the unicast MAC corresponding to the Where a return path is required the unicast MAC corresponding to the
originating interface and a VID selected from the configured VID/ESP- originating interface and a VID selected from the configured VID/ESP-
MAC DA range is encoded as an Ethernet label in the UPSTREAM_LABEL MAC DA range is encoded as an Ethernet label in the UPSTREAM_LABEL
object. object.
4.3.2 Maintenance Procedures 4.3.2. Maintenance Procedures
Maintenance and modification to a P2MP tree can be achieved by a Maintenance and modification to a P2MP tree can be achieved by a
number of means. The preferred technique is to modify existing VLAN number of means. The preferred technique is to modify existing VLAN
configuration vs. assignment of a new label and completely configuration vs. assignment of a new label and completely
constructing a new tree. constructing a new tree.
Make before break on a live tree reusing existing label assignments Make before break on a live tree reusing existing label assignments
requires a 1:1 or 1+1 construct. The protection switch state of the requires a 1:1 or 1+1 construct. The protection switch state of the
traffic is forced on the working tree and locked (PS not allowed) traffic is forced on the working tree and locked (PS not allowed)
while the backup tree is modified. Explicit path tear of leaves to while the backup tree is modified. Explicit path tear of leaves to be
be modified is required to ensure no loops are left behind as modified is required to ensure no loops are left behind as artifacts
artifacts of tree modification. Once modifications are complete, a of tree modification. Once modifications are complete, a forced
forced switch to the backup tree occurs and the original tree may be switch to the backup tree occurs and the original tree may be
similarly modified. This also suggests that 1+1 or 1:1 resilience similarly modified. This also suggests that 1+1 or 1:1 resilience can
can be achieved for P2MP trees for any single failure (switch on any be achieved for P2MP trees for any single failure (switch on any
failure and use restoration techniques to repair the failed tree). failure and use restoration techniques to repair the failed tree).
4.4 Ethernet Label 4.4. Ethernet Label
The Ethernet label is a new generalized label with a suggested The Ethernet label is a new generalized label with a suggested format
format of: of:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| ESP VID | ESP MAC (highest 2 bytes) | |0 0 0 0| ESP VID | ESP MAC (highest 2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESP MAC | | ESP MAC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format can be used to carry P2P and P2MP labels. For P2P labels This format can be used to carry P2P and P2MP labels. For P2P labels
the fields specify ESP <VID, MAC DA>. The semantics for P2MP label o the fields specify ESP <VID, MAC DA>. The semantics for a P2MP label
using a MMAC DA is that that the label is passed unchanged. This using a MMAC DA is that that the label is passed unchanged. This
label is also a domain wide label. This has similarity to the way label is also a domain wide label. This has similarity to the way in
in which a wavelength label is handled at an intermediate switch which a wavelength label is handled at an intermediate switch that
that cannot perform wavelength conversion, and is described in cannot perform wavelength conversion, and is described in [RFC3473].
[RFC3473]. The option to allow just a Multicast VID to be signaled
without a MAC (A zero MAC) is for cases where a single VID is
desired to be signaled for P2MP trees in cases where a multicast MAC
is not desired.
These domain wide labels are allocated to switches that control the Label Allocation for Domain wide labels is similar to other label
assignment of labels. There are two options for Ethernet MAC based switching technologies with the exception that the labels are owned
domain wide unique labels. One option is to allocate the ESP-MAC DAs by the switch where the path is terminated. In Ethernet, unique MAC
from globally unique addresses assigned to the either the switch based labels can be created using one of two methods. One option is
manufacturer or the owner. The other option is to use ESP-MAC DAs to allocate the ESP-MAC DAs from globally unique addresses assigned
out of the local admin space and ensue these labels are unique to the either the switch manufacturer. The other option is to use
within the domain. This local ESP-MAC DA space does not have to be ESP-MAC DAs out of the local admin space and ensure these labels are
globally unique because the labels are only valid within a single unique within the domain. Labels only have significance within the
provider domain. domain.
In the case of local label allocation there is less administrative In the case of local label allocation there is no need to use
overhead to allocate labels. However when using configuration, a globally assigned OUIs. However when using this configuration, some
tool would have to perform a consistency check to make sure that way of ensuring label consistency should be provided to make sure
labels were unique. When using GMPLS signaling it is assumed a that labels were unique. When using GMPLS signaling it is assumed a
unique pool of labels would be assigned to each switch. The ESP-MAC unique pool of labels would be owned or assigned to each switch. The
DA addresses are domain wide unique and so is the combination of ESP ESP-MAC DA addresses are domain wide unique and so is the combination
<VID, MAC DA>. It is intended that the ESP <VID, MAC DA> be only of ESP <VID, MAC DA>. It is intended that the ESP <VID, MAC DA> be
used by one destination. However, should an error occur and a only used by one destination. However, should an error occur and a
somehow a duplicate label be assigned to one or more destination somehow a duplicate label be assigned to one or more destination
switches GMPLS signaling procedures would allow the first assignment switches GMPLS signaling procedures would allow the first assignment
of the label and prevent any duplicate label from colliding. If a of the label and prevent any duplicate label from colliding. If a
collision occurs an alarm would be generated. In fact some of these collision occurs an alarm would be generated. In fact some of these
procedures have been defined in GMPLS control of photonic networks procedures have been defined in GMPLS control of photonic networks
where a lambda may exist as a form of domain wide label. where a lambda may exist as a form of domain wide label.
4.5 OAM MEP ID and MA ID synchronization 4.5. OAM MEP ID and MA ID synchronization
This section is aligned with [IEEE 802.1Qay]. At present it Ethernet This section is aligned with [IEEE 802.1Qay]. At present Ethernet OAM
OAM is signaled in Ethernet packet data units. is signaled in Ethernet protocol data units. Extensions to GMPLS
[OAM-EXT] are proposed to automatically setup OAM for Ethernet LSPs.
The Maintenance end point IDs (MEP IDs) and maintenance association The Maintenance association point IDs (MEP IDs) and maintenance
IDs for the switched path endpoints can be synchronized using the association IDs for the switched path endpoints can be synchronized
ETH-MCC (maintenance communication channel) transaction set once the using the ETH-MCC (maintenance communication channel) transaction set
switched path has been established. once the switched path has been established.
MEPs are located at the endpoints of the Ethernet LSP. Typical MEPs are located at the endpoints of the Ethernet LSP. Typical
configuration associated with a MEP is Maintenance Domain Name, configuration associated with a MEP is Maintenance Domain Name, Short
Short Maintenance Association Name, and MA Level, MEP ID, and CCM Maintenance Association Name, and MD Level, MEP ID, and CCM
transmission rate (when ETH-CC functionality is desired). As part of transmission rate (when ETH-CC functionality is desired). As part of
the synchronization, it is verified that the Maintenance Domain the synchronization, it is verified that the Maintenance Domain Name,
Name, Short Maintenance Association Name, MA Level, and CCM Short Maintenance Association Name, MD Level, and CCM transmission
transmission rate are the same. It is also determined that MEP IDs rate are the same. It is also determined that MEP IDs are unique for
are unique for each MEP. each MEP.
Besides the unicast CCM functionality, the PBB-TE MEPs can also Besides the unicast CCM functionality, the PBB-TE MEPs can also offer
offer the LBM/LBR and LMM/LMR functionalities for on-demand the LBM/LBR and LMM/LMR functionalities for on-demand connectivity
connectivity verification and loss measurement purposes. verification and loss measurement purposes.
4.6 Protection Paths 4.6. Protection Paths
The IEEE is currently defining protection procedures for PBB-TE The IEEE is currently defining protection procedures for PBB-TE [IEEE
[IEEE 802.1Qay]. This section will be updated when these procedures 802.1Qay]. This section will be updated when these procedures are
are documented. documented.
When protection is used for path recovery it is required to When protection is used for path recovery it is required to associate
associate the working and protection paths into a protection group. the working and protection paths into a protection group. This is
This is achieved as defined in [RFC4872] and [RFC4873] using the achieved as defined in [RFC4872] and [RFC4873] using the ASSOCIATION
ASSOCIATION and PROTECTION objects. Protection may be used for P2P and PROTECTION objects. Protection may be used for P2P VID/ESP-MAC
VID/ESP-MAC DA, P2MP VID/ESP-MAC DA and P2MP VID configured modes of DA, P2MP VID/ESP-MMAC DA and P2MP VID configured modes of operation.
operation. The 'P' bit in the protection object indicates the role The 'P' bit in the protection object indicates the role (working or
(working or protection) of the LSP currently being signaled. protection) of the LSP currently being signaled.
If the initiating switch wishes to use G.8031 [G-8031] data plane If the initiating switch wishes to use G.8031 [G-8031] data plane
protection switching coordination (vs. control plane notifications), protection switching coordination (vs. control plane notifications),
it sets the N bit to 1 in the protection object. This must be it sets the N bit to 1 in the protection object. This must be
consistently applied for all paths associated as a protection group. consistently applied for all paths associated as a protection group.
If the terminating switch does not support G.8031, the error If the terminating switch does not support G.8031, the error
"Admission Control Failure/Unsupported Notification Type" is used. "Admission Control Failure/Unsupported Notification Type" is used.
5. Error conditions 5. Error conditions
The following errors have been identified as being unique to these The following errors have been identified as being unique to these
procedures and in addition to those already defined. This will be procedures and in addition to those already defined. This will be
addressed in a proper IANA considerations section in a future addressed in a proper IANA considerations section in a future version
version of the document: of the document:
5.1 Invalid ESP-VID value for PBB-TE MSTI range 5.1. Invalid ESP-VID value for PBB-TE MSTI range
The originator of the error is not configured to use the ESP-VID The originator of the error is not configured to use the ESP-VID
value in conjunction with GMPLS signaling of <ESP: VID, MAC DA > value in conjunction with GMPLS signaling of <ESP: VID, MAC DA >
tuples. This may be any switch along the path. tuples. This may be originated by any switch along the path.
5.2 Invalid MAC Address 5.2. Invalid MAC Address
The MAC address is out of a reserved range that cannot be used by The MAC address is out of a reserved range that cannot be used by the
then node which is processing the address. While almost all MAC switch which is processing the address. While almost all MAC
addresses are valid there are a small number of reserved MAC addresses are valid there are a small number of IEEE reserved MAC
addresses. addresses.
5.3 Invalid ERO for UPSTREAM_LABEL Object 5.3. Invalid ERO for UPSTREAM_LABEL Object
The ERO offered has discontinuities with the identified ESP- The ERO offered has discontinuities with the identified ESP-
VID/ESP-MAC DA path in the UPSTREAM_LABEL object. VID/ESP-MAC DA path in the UPSTREAM_LABEL object.
5.4 Invalid ERO for LABEL_SET Object 5.4. Invalid ERO for LABEL_SET Object
The ERO offered has discontinuities with the identified ESP-VID/ESP- The ERO offered has discontinuities with the identified ESP-VID/ESP-
MAC DA path in the LABEL_SET object. MAC DA path in the LABEL_SET object.
5.5 Switch is not ESP P2MP capable 5.5. Switch is not ESP P2MP capable
This error may arise only in P2MP VID Tree allocation. This error may arise only in P2MP Tree allocation.
5.6 Invalid ESP-VID in UPSTREAM_LABEL object 5.6. Invalid ESP-VID in UPSTREAM_LABEL object
The ESP-VID in the UPSTREAM_LABEL object for the "asymmetrical ESP- The ESP-VID in the UPSTREAM_LABEL object for the "asymmetrical ESP-
VID" P2MP tree did not correspond to the ESP-VID used in previous VID" P2MP tree did not correspond to the ESP-VID used in previous
transactions. transactions.
6. Deployment Scenarios 6. Deployment Scenarios
This technique of GMPLS controlled Ethernet switching is applicable Deployment scenarios are covered in [ARCH]. This section will detail
to all deployment scenarios considered by the design team [CCAMP- more specific PBB-TE deployment scenarios in a later revision of this
ETHERNET]. document.
7. Security Considerations 7. Security Considerations
The architecture assumes that the GMPLS controlled Ethernet subnet The architecture assumes that the GMPLS controlled Ethernet subnet
consists of trusted devices and that the UNI ports to the domain are consists of trusted devices and that the UNI ports or in this case
untrusted. Care is required to ensure untrusted access to the trusted BEB Ethernet UNI Ports to the domain are untrusted. Care is required
domain does not occur. Where GMPLS is applied to the control of VLAN to ensure untrusted access to the trusted domain does not occur.
only, the commonly known techniques for mitigation of Ethernet DOS Where GMPLS is applied to the control of VLAN only, the commonly
attacks may be required on UNI ports. known techniques for mitigation of Ethernet DOS attacks may be
required on UNI ports.
8. IANA Considerations 8. IANA Considerations
New values are required for signaling and error codes as indicated. New values are required for signaling and error codes as indicated.
This section will be completed in a later version. This section will be completed in a later version.
9. References 9. References
9.1 Normative References 9.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 [ARCH] Fedyk, D. Berger, L., Andersson L., "GMPLS Ethernet Label
Switching Architecture and Framework", work in progress. Switching Architecture and Framework", work in progress.
[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.
9.2 Informative References [RFC3945] Mannie, E. et.al., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", IETF RFC 3945, October 2004.
9.2. Informative References
[IEEE 802.1Qay] "IEEE standard for Provider Backbone Bridges Traffic [IEEE 802.1Qay] "IEEE standard for Provider Backbone Bridges Traffic
Engineering", work in progress. Engineering", work in progress.
[RFC4115] Aboul-Magd, O. et.al. "A Differentiated Service Two-Rate, [RFC4115] Aboul-Magd, O. et.al. "A Differentiated Service Two-Rate,
Three-Color Marker with Efficient Handling of in-Profile Traffic", Three-Color Marker with Efficient Handling of in-Profile Traffic",
[G-8031] ITU-T Draft Recommendation G.8031, Ethernet Protection [G-8031] ITU-T Recommendation G.8031 (2006), Ethernet Protection
Switching. Switching.
[IEEE 802.1AB] "IEEE Standard for Local and Metropolitan Area [IEEE 802.1AB] "IEEE Standard for Local and Metropolitan Area
Networks, Station and Media Access Control Connectivity Networks, Station and Media Access Control Connectivity
Discovery". Discovery".
[IEEE 802.1ag] "IEEE Draft Standard for Connectivity Fault [IEEE 802.1ag] "IEEE Standard for Connectivity Fault
Management", work in progress. Management", (2007).
[IEEE 802.1ah] "IEEE standard for Provider Backbone Bridges", work in [IEEE 802.1ah] "IEEE Standard for Local and Metropolitan Area
progress. Networks - Virtual Bridged Local Area Networks
- Amendment 6: Provider Backbone Bridges", (2008)
[RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" RFC4204, [RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" RFC4204,
October 2005 October 2005
[MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services [MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services
Definitions - Phase I". Definitions - Phase I".
[MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet Services [MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet Services
Attributes Phase 1". Attributes Phase 1".
[RFC3270] Le Faucheur, F. et.al., "Multi-Protocol Label Switching [RFC3270] Le Faucheur, F. et.al., "Multi-Protocol Label Switching
skipping to change at page 18, line 32 skipping to change at page 20, line 32
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.
[RFC3209] Awduche et.al., "RSVP-TE: Extensions to RSVP for LSP [RFC3209] Awduche et.al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels, IETF RFC 3209, December 2001. Tunnels, IETF RFC 3209, December 2001.
[Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM Functions [Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM Functions
and Mechanisms for Ethernet based Networks ", work in progress. and Mechanisms for Ethernet based Networks ", (2006).
[ADDRESS] Shimoto, K., Papneja, R., Rabbat, R., "Use of Addresses in [RFC4990] Shimoto, K., Papneja, R., Rabbat, R., "Use of Addresses in
Generalized Multi-Protocol Label Switching (GMPLS) Networks", Generalized Multi-Protocol Label Switching (GMPLS) Networks",
work in progress. IETF RFC4990, September 2007.
[CCAMP-ETHERNET] Papadimitriou, D. et.al, "A Framework for [OAM-EXT] Takacs, A., Gero, B., "GMPLS RSVP-TE Extensions to Control
Generalized MPLS (GMPLS) Ethernet", internet draft, draft- Ethernet OAM", work in progress.
10. Author's Address 10. Acknowledgments
The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen
Shew, Dave Martin and Sandra Ballarte for their contributions to this
document.
11. Author's Address
Don Fedyk Don Fedyk
Nortel Networks Nortel Networks
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA, 01821 Billerica, MA, 01821
Email: dwfedyk@nortel.com Email: dwfedyk@nortel.com
David Allan David Allan
Nortel Networks Nortel Networks
3500 Carling Ave. 3500 Carling Ave.
skipping to change at page 19, line 50 skipping to change at page 22, line 24
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
11. Intellectual Property Statement A. Rational and mechanism for PBB_TE Ethernet Forwarding
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
12. Disclaimer of Validity
"This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
13. Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
14. Acknowledgments
The authors would like to thank Dinesh Mohan, Nigel Bragg, Stephen
Shew and Sandra Ballarte for their contributions to this document.
Rational and mechanism for PBB_TE Ethernet Forwarding
This appendix describes work currently being undertaken in the 801.1 This appendix describes work currently being undertaken in the 802.1
PBB-TE [IEEE 802.1Qay] project. This information is for reference PBB-TE [IEEE 802.1Qay] project. This information is for reference
only and will be removed when 802.1Qay becomes mature. This text only and will be removed when 802.1Qay becomes mature. This text
captures some of the original rational for changing Ethernet captures some of the original rational for changing Ethernet
forwarding. The PBB-TE [IEEE 802.1Qay] document simply documents the forwarding. The PBB-TE [IEEE 802.1Qay] document simply documents the
PBB-TE data plane. PBB-TE data plane.
Ethernet as specified today is a complete system consisting of a Ethernet as specified today is a complete system consisting of a data
data plane and a number of control plane functions. Spanning tree, plane and a number of control plane functions. Spanning tree, data
data plane flooding and MAC learning combine to populate forwarding plane flooding and MAC learning combine to populate forwarding tables
tables and produce resilient any-to-any behavior in a bridged and produce resilient any-to-any behavior in a bridged network.
network.
Ethernet consists of a very simple and reliable data plane that has Ethernet consists of a very simple and reliable data plane that has
been optimized and mass produced. By simply disabling some Ethernet been optimized and mass produced. By simply disabling some Ethernet
control plane functionality, it is possible to employ alternative control plane functionality, it is possible to employ alternative
control planes and obtain different forwarding behaviors. control planes and obtain different forwarding behaviors.
Customer Provider Provider Customer Provider Provider
Bridge/ Bridge Backbone Bridge/ Bridge Backbone
Bridge Bridge
C-MAC/C-VID------------------802.1Q -------------------C-MAC-CVID C-MAC/C-VID------------------802.1Q -------------------C-MAC-CVID
S-VID-----------802.1ad------------S-VID S-VID-----------802.1ad------------S-VID
B-MAC---802.1ah---B-MAC B-MAC---802.1ah---B-MAC
B-VID---802.1ah---B-VID B-VID---802.1ah---B-VID
Figure 1 802.1 MAC/VLAN Hierarchy Figure A.1 802.1 MAC/VLAN Hierarchy
Recent works in IETF Pseudo Wire Emulation [RFC3985] and IEEE 802 Recent works in IETF Pseudo Wire Emulation [RFC3985] and IEEE 802 are
are defining a separation of Ethernet functions permitting an defining a separation of Ethernet functions permitting an increasing
increasing degree of provider control. The result is that the degree of provider control. The result is that the Ethernet service
Ethernet service to the customer appears the same, yet the provider to the customer appears the same, yet the provider components and
components and behaviors have become decoupled from the customer behaviors have become decoupled from the customer presentation and
presentation and the provider has gained control of all VID/DMAC the provider has gained control of all VID/B-MAC endpoints.
endpoints.
One example of this is the 802.1ah work in hierarchical bridging One example of this is the 802.1ah work in hierarchical bridging
whereby customer Ethernet frames are fully encapsulated into a whereby customer Ethernet frames are fully encapsulated into a
provider Ethernet frame, isolating the customer VID/DMAC space from provider Ethernet frame, isolating the customer VID/C-MAC space from
the provider VID/DMAC space. In this case, the forwarding behavior the provider VID/B-MAC space. In this case, the forwarding behavior
of the of the Backbone MAC in the provider's network is as per of the of the Backbone MAC in the provider's network is as per
802.1Q. 802.1Q.
The Ethernet data plane provides protocol multiplexing via the ether The Ethernet data plane provides protocol multiplexing via the
type field which allows encapsulation of different protocols Ethertype field which allows encapsulation of different protocols
supporting various applications. More recently, the Carrier Ethernet supporting various applications. More recently, the Carrier Ethernet
effort has created provider and customer separation that enables effort has created provider and customer separation that enables
another level of multiplexing. This in effect creates provider MAC another level of multiplexing. This in effect creates provider MAC
endpoints in the Ethernet sub-network controlled by the provider. In endpoints in the Ethernet sub-network controlled by the provider. In
this appendix we concentrate on the provider solutions and therefore this appendix we concentrate on the provider solutions and therefore
subsequent references to VLAN, VID and MAC refer to those under subsequent references to VLAN, VID and MAC refer to those under
provider control, be it in the backbone layer of 802.1ah. The provider control, be it in the backbone layer of 802.1ah. The
Customer Ethernet service is the same native Ethernet service with Customer Ethernet service is the same native Ethernet service with
functions such as bridging, learning and spanning trees all functions such as bridging, learning and spanning trees all
functioning over the provider infrastructure. functioning over the provider infrastructure.
Bridging offers a simple solution for any-to-any connectivity within Bridging offers a simple solution for any-to-any connectivity within
a VLAN partition via the Spanning tree, flooding and MAC learning. a VLAN partition via the Spanning tree, flooding and MAC learning.
Spanning tree provides some unnecessary capabilities for P2P Spanning tree provides some unnecessary capabilities for P2P services
services and since the Spanning tree must interconnect all MACs with and since the Spanning tree must interconnect all MACs with the same
the same VLAN IDs (VIDs) it consumes a scarce resource (VIDs). In VLAN IDs (VIDs) it consumes a scarce resource (VIDs). In this
this document we present that it is easier to modify Ethernet to document we present that it is easier to modify Ethernet to scale
scale engineered P2P services and this is the approach we take with engineered P2P services and this is the approach we take with PBB-TE.
PBB-TE. (The number of usable VLANs IDs in conventional Ethernet (The number of usable VLANs IDs in conventional Ethernet bridging is
bridging is constrained to 4094, therefore the use of VLAN only constrained to 4094, therefore the use of VLAN only configuration for
configuration for all forwarding could be limited for some all forwarding could be limited for some applications where large
applications where large number of P2P connections are required.) number of P2P connections are required.) This is because in
This is because in Ethernet, each Spanning tree is associated with Ethernet, each Spanning tree is associated with one or more VLAN IDs.
one or more VLAN IDs. Also Port membership in a VLAN is configured Also Port membership in a VLAN is configured which controls the
which controls the connectivity of all MAC interfaces participating connectivity of all MAC interfaces participating in the VLAN.
in the VLAN.
The roots for PBB-TE capability exist in the Ethernet management The roots for PBB-TE capability exist in the Ethernet management
plane. The management of Ethernet switches provides for static plane. The management of Ethernet switches provides for static
configuration of Ethernet forwarding. The Ethernet Control plane configuration of Ethernet forwarding. The Ethernet Control plane
allows for forwarding entries that are statically provisioned or allows for forwarding entries that are statically provisioned or
configured. In this document we are expanding the meaning of configured. In this document we are expanding the meaning of
"configured" from an Ethernet Control plane sense to mean either "configured" from an Ethernet Control plane sense to mean either
provisioned, or controlled by GMPLS. The connectivity aspects of provisioned, or controlled by GMPLS. The connectivity aspects of
Ethernet forwarding is based upon VLANs and MAC addresses. In other Ethernet forwarding is based upon VLANs and MAC addresses. In other
words the VLAN + DMAC are an Ethernet Label that can be looked up at words the VLAN + DMAC are an Ethernet Label that can be looked up at
each switch to determine the egress link (or links in the case of each switch to determine the egress link (or links in the case of
link aggregation). link aggregation).
This is a finer granularity than traditional VLAN networks since This is a finer granularity than traditional VLAN networks since each
each P2P connection is independent. By provisioning MAC addresses P2P connection is independent. By provisioning MAC addresses
independently of Spanning tree in a domain, both the VLAN and the independently of Spanning tree in a domain, both the VLAN and the
VLAN/DMAC configured forwarding can be exploited. This greatly VLAN/DMAC configured forwarding can be exploited. This greatly
extends the scalability of what can be achieved in a pure Ethernet extends the scalability of what can be achieved in a pure Ethernet
bridged sub network. bridged sub network.
The global/domain wide uniqueness and semantics of MAC addresses as The global/domain wide uniqueness and semantics of MAC addresses as
interface names or multicast group addresses has been preserved. (In interface names or multicast group addresses has been preserved. (In
Ethernet overlap of MAC addresses across VLANs is allowed. However Ethernet overlap of MAC addresses across VLANs is allowed. However
for PBB-TE MAC addresses should be unique for all VLANs assigned to for PBB-TE MAC addresses should be unique for all VLANs assigned to
PBB-TE. With PBB-TE it is an operational choice if the operator uses PBB-TE. With PBB-TE it is an operational choice if the operator uses
PBT-TE labels out of the global MAC address space or the local admin PBT-TE labels out of the global MAC address space or the local admin
space.) We then redefine the semantics associated with space.) We then redefine the semantics associated with administration
administration and uses of VLAN values for the case of explicit and uses of VLAN values for the case of explicit forwarding such as
forwarding such as you get with statically configured Ethernet. with statically configured Ethernet.
The PBB_TE is Ethernet Forwarding where configured VID + DMAC The PBB_TE is Ethernet Forwarding where configured VID + DMAC provide
provide a forwarding table that is consistent with existing PBB and a forwarding table that is consistent with existing PBB and Ethernet
Ethernet switching. At the same time it provides domain wide labels switching. At the same time it provides domain wide labels that can
that can be controlled by a common GMPLS control plane. This makes be controlled by a common GMPLS control plane. This makes GMPLS
GMPLS control and resource management procedures ideal to create control and resource management procedures ideal to create paths. The
paths. The outcome is that the GMPLS control plane can be utilized outcome is that the GMPLS control plane can be utilized to set up the
to set up the following atomic modes of connectivity: following atomic modes of connectivity:
1) P2P connectivity and MP2P multiplexed connectivity based 1) P2P connectivity and MP2P multiplexed connectivity based
on configuration of unicast MAC addresses in conjunction on configuration of unicast MAC addresses in conjunction
with a VID from a set of pre-configured VIDs. with a VID from a set of pre-configured VIDs.
2) P2MP connectivity based on configuration of multicast MAC 2) P2MP connectivity based on configuration of multicast MAC
address in conjunction with a VID from a set of pre- address in conjunction with a VID from a set of pre-
configured VIDs. This corresponds to (Source, Group) or configured VIDs. This corresponds to (Source, Group) or
(S,G) multicast. (S,G) multicast.
3) P2MP connectivity based on configuration of VID port 3) P2MP connectivity based on configuration of VID port
membership. This corresponds to (S,*) or (*,*) multicast membership. This corresponds to (S,*) or (*,*) multicast
skipping to change at page 23, line 39 skipping to change at page 25, line 24
The modes above are not completely distinct. Some modes involve The modes above are not completely distinct. Some modes involve
combinations of P2P connections in one direction and MP connectivity combinations of P2P connections in one direction and MP connectivity
in the other direction. Also, more than one mode may be combined in in the other direction. Also, more than one mode may be combined in
a single GMPLS transaction. One example is the incremental addition a single GMPLS transaction. One example is the incremental addition
of a leaf to a P2MP tree with a corresponding MP2P return path of a leaf to a P2MP tree with a corresponding MP2P return path
(analogous to a root initiated join). (analogous to a root initiated join).
In order to realize the above connectivity modes, a partition of the In order to realize the above connectivity modes, a partition of the
VLAN IDs from traditional Ethernet needs to be established. The VLAN IDs from traditional Ethernet needs to be established. The
partition allows for a pool of Ethernet labels for manual partition allows for a pool of Ethernet labels for manual
configuration and/or for GMPLS control plane usage. The VID configuration and/or for GMPLS control plane usage. The VID partition
partition actually consists of a "configured VID/DMAC range" and actually consists of a "configured VID/DMAC range" and "configured
"configured VID range" since in some instances the label is a VID/ VID range" since in some instances the label is a VID/ DMAC and
DMAC and sometimes the label is a VID/Multicast DMAC. sometimes the label is a VID/Multicast DMAC.
A 1. Overview of configuration of VID/DMAC tuples A.1. Overview of configuration of VID/DMAC tuples
Statically configured MAC and VID entries are a complete 60 bit Statically configured MAC and VID entries are a complete 60 bit
lookup. The basic operation of an Ethernet switch is filtering on lookup. The basic operation of an Ethernet switch is filtering on VID
VID and forwarding on DMAC. The resulting operation is the same as and forwarding on DMAC. The resulting operation is the same as
performing a full 60 bit lookup (VID (12) + DMAC(48)) for P2P performing a full 60 bit lookup (VID (12) + DMAC(48)) for P2P
operations, only requiring uniqueness of the full 60 bits for operations, only requiring uniqueness of the full 60 bits for
forwarding to resolve correctly. This is an Ethernet domain wide forwarding to resolve correctly. This is an Ethernet domain wide
label. label.
Complete route freedom is available for each domain wide label (60 Complete route freedom is available for each domain wide label (60
bit VLAN/DMAC tuple) and the ability to define multiple connectivity bit VLAN/DMAC tuple) and the ability to define multiple connectivity
instances or paths per DMAC for each of the VIDs in the "configured instances or paths per DMAC for each of the VIDs in the "configured
VID/DMAC range". VID/DMAC range".
The semantics of MAC addresses are preserved, and simply broaden the The semantics of MAC addresses are preserved, and simply broaden the
potential interpretations of VLAN ID from spanning tree identifier potential interpretations of VLAN ID from spanning tree identifier to
to topology instance identifier. Therefore, operation of both topology instance identifier. Therefore, operation of both standard
standard bridging and configured unicast/multicast operation is bridging and configured unicast/multicast operation is available side
available side by side. The VID space is partitioned and a range of by side. The VID space is partitioned and a range of VIDs is
VIDs is allocated(say 'n' VIDs) as only significant when combined allocated(say 'n' VIDs) as only significant when combined with a
with a configured DMAC address (the aforementioned "configured configured DMAC address (the aforementioned "configured VID/DMAC
VID/DMAC range" of VIDs). A VID in that range is considered as an range" of VIDs). A VID in that range is considered as an individual
individual connectivity instance identifier for a configured P2P connectivity instance identifier for a configured P2P path
path terminating at the associated DMAC address. Or in the case of terminating at the associated DMAC address. Or in the case of P2MP, a
P2MP, a P2MP multicast tree corresponding to the destination P2MP multicast tree corresponding to the destination multicast group
multicast group address. Note that this is destination based address. Note that this is destination based forwarding consistent
forwarding consistent with how Ethernet works today. The only thing with how Ethernet works today. The only thing changed is the
changed is the mechanism of populating the forwarding tables. mechanism of populating the forwarding tables.
Ethernet MAC addresses are typically globally unique since the 48 Ethernet MAC addresses are typically globally unique since the 48
bits consists of 24 bit Organizational Unique Identifier and a 24 bits consists of 24 bit Organizational Unique Identifier and a 24 bit
bit serial number. There is also a bit set aside for Multicast and serial number. There is also a bit set aside for Multicast and for
for local addresses out of the OUI field. We define domain wide as local addresses out of the OUI field. We define domain wide as within
within a single organization, or more strictly within a single a single organization, or more strictly within a single network
network within an organization. For provider MAC addresses that will within an organization. For provider MAC addresses that will only be
only be used in a domain wide sense we can define MAC addresses out used in a domain wide sense we can define MAC addresses out of a
of a either the local space or the global space since they both have either the local space or the global space since they both have the
the domain wide unique property. When used in the context of GMPLS, domain wide unique property. When used in the context of GMPLS, it is
it is useful to think of a domain wide pool of labels where switches useful to think of a domain wide pool of labels where switches are
are assigned a set of MAC addresses. These labels are assigned assigned a set of MAC addresses. These labels are assigned traffic
traffic that terminates on the respective switches. that terminates on the respective switches.
It is also worth noting that unique identification of source in the It is also worth noting that unique identification of source in the
form of the ESP-MAC SA is carried e2e in the MAC header. So although form of the ESP-MAC SA is carried e2e in the MAC header. So although
we have a 60 bit domain wide unique label, it may be shared by we have a 60 bit domain wide unique label, it may be shared by
multiple sources and the full connection identifier for an multiple sources and the full connection identifier for an individual
individual P2P instance is 108 bits (ESP-MAC SA, VID and DMAC). The P2P instance is 108 bits (ESP-MAC SA, VID and DMAC). The ESP-MAC SA
ESP-MAC SA is not referenced in forwarding operations but it would is not referenced in forwarding operations but it would allow
allow additional context for tracing or other operations at the end additional context for tracing or other operations at the end of the
of the path. path.
For multicast group addresses, the VID/DMAC concatenated label can For multicast group addresses, the VID/DMAC concatenated label can be
be distributed by the source but label assignment (as it encodes distributed by the source but label assignment (as it encodes global
global multicast group information) requires coordination within the multicast group information) requires coordination within the GMPLS
GMPLS controlled domain. controlled domain.
As mentioned earlier, this technique results in a single unique and As mentioned earlier, this technique results in a single unique and
invariant identifier, in our case a VID/DMAC label associated with invariant identifier, in our case a VID/DMAC label associated with
the path termination or the multicast group. There can be up to the path termination or the multicast group. There can be up to 4094
4094 labels to any one MAC address. However, practically, from labels to any one MAC address. However, practically, from an
Ethernet network wide aspect; there would be only a handful of VLANs Ethernet network wide aspect; there would be only a handful of VLANs
allocated for PBB-TE. In addition, all 48 bits are not completely allocated for PBB-TE. In addition, all 48 bits are not completely
available for the MAC addresses. One way to maximize the space is available for the MAC addresses. One way to maximize the space is to
to use the locally administered space. This is a large number for use the locally administered space. This is a large number for
P2P applications and even larger when shared or multiplexed P2P applications and even larger when shared or multiplexed
forwarding is leveraged. In practice, most network scaling forwarding is leveraged. In practice, most network scaling
requirements may be met via allocation of only a small portion of requirements may be met via allocation of only a small portion of the
the VID space, to the configured VID/DMAC range. The result is VID space, to the configured VID/DMAC range. The result is minimal
minimal impact on the number of remaining bridging VLANs that can be impact on the number of remaining bridging VLANs that can be
concurrently supported. concurrently supported.
In order to use this unique 60 bit label, we disable the normal In order to use this unique 60 bit label, we disable the normal
mechanisms by which Ethernet populates the forwarding table for the mechanisms by which Ethernet populates the forwarding table for the
allocated range of VIDs. When a path is setup, for a specific label allocated range of VIDs. When a path is setup, for a specific label
across a contiguous sequence of Ethernet switches, a unidirectional across a contiguous sequence of Ethernet switches, a unidirectional
connection is the functional building block for an Ethernet Label connection is the functional building block for an Ethernet Label
Switched path (Eth-LSP). Switched path (Eth-LSP).
In P2P mode a bidirectional path is composed of two unidirectional In P2P mode a bidirectional path is composed of two unidirectional
paths that are created with a single RSVP-TE session. The technique paths that are created with a single RSVP-TE session. The technique
does not require the VID to be common in both directions. However, does not require the VID to be common in both directions. However,
keeping in line with regular Ethernet these paths are symmetrical keeping in line with regular Ethernet these paths are symmetrical
such that a single bidirectional connection is composed of two such that a single bidirectional connection is composed of two
unidirectional paths that have common routing (i.e. traverse the unidirectional paths that have common routing (i.e. traverse the same
same switches and links) in the network and hence share the same switches and links) in the network and hence share the same fate.
fate.
In P2MP mode a bidirectional path is composed of a unidirectional In P2MP mode a bidirectional path is composed of a unidirectional
multicast tree and a number of P2P paths from the leaves of the tree multicast tree and a number of P2P paths from the leaves of the tree
to the root. Similarly these paths may have bandwidth and must have to the root. Similarly these paths may have bandwidth and must have
common routing as in the P2P case. common routing as in the P2P case.
There are a few modifications required to standard Ethernet to make There are a few modifications required to standard Ethernet to make
this approach robust: this approach robust:
1. In Standard Ethernet, discontinuities in forwarding table 1. In Standard Ethernet, discrepancies in forwarding table
configuration in the path of a connection will normally result in configuration in the path of a connection will normally result in
packets being flooded as "unknown". For configured operation (e.g. packets being flooded as "unknown". For configured operation (e.g.
PBB-TE), unknown addresses are indicative of a fault or PBB-TE), unknown addresses are indicative of a fault or configuration
configuration error and the flooding of these is undesirable in error and the flooding of these is undesirable in meshed topologies.
meshed topologies. Therefore flooding of "unknown" unicast/multicast Therefore flooding of "unknown" unicast/multicast MAC addresses must
MAC addresses must be disabled for the "configured VID/DMAC range". be disabled for the "configured VID/DMAC range".
2. MAC learning is not required, and although it will not interfere 2. MAC learning is not required, and although it will not interfere
with management/control population of the forwarding tables, since with management/control population of the forwarding tables, since
static entries are not overridden, it appears prudent to explicitly static entries are not overridden, it appears prudent to explicitly
disable MAC learning for the configured VID/DMAC and VID range. disable MAC learning for the configured VID/DMAC and VID range.
3. Spanning tree is disabled for the allocated VID/DMAC and VID 3. Spanning tree is disabled for the allocated VID/DMAC and VID range
range and port blocking must be disabled to achieve complete and port blocking must be disabled to achieve complete configured
configured route freedom. As noted earlier, it is a control plane route freedom. As noted earlier, it is a control plane requirement to
requirement to ensure configured paths are loop free. ensure configured paths are loop free.
All three modifications described above are within the scope of All three modifications described above are within the scope of
acceptable configuration options defined in IEEE802.1Q acceptable configuration options defined in IEEE802.1Q
specification. specification.
A 2. Overview of configuration of VID port membership A.2 Overview of configuration of VID port membership
Procedures almost identical to that for configuration of P2P Procedures almost identical to that for configuration of P2P VID/DMAC
VID/DMAC tuples can also be used for the incremental configuration tuples can also be used for the incremental configuration of P2MP VID
of P2MP VID trees. For the replication of forwarding in this case trees. For the replication of forwarding in this case the label is
the label is common for the multipoint destinations. The MAC field common for the multipoint destinations. The MAC field is set to
is set to multicast address and is common to the multicast multicast address and is common to the multicast community. The VID
community. The VID is a distinguisher common to the multicast is a distinguisher common to the multicast community. The signaling
community. The signaling procedures are as per that for [RFC4875]. procedures are per that for [RFC4875].
Since VID translation is relatively new and is not a ubiquitously Since VID translation is relatively new and is not a ubiquitously
deployed capability, we consider a VID to be a domain global value. deployed capability, we consider a VID to be a domain global value.
Therefore, the VID value to be used by the originating switch may be Therefore, the VID value to be used by the originating switch may be
assigned by management and nominally is required to be invariant assigned by management and nominally is required to be invariant
across the network. The ability to indicate permissibility of across the network. The ability to indicate permissibility of
translation will be addressed in a future version of the document. translation will be addressed in a future version of the document.
A procedure known as "asymmetrical VID" may be employed to constrain A procedure known as "asymmetrical VID" may be employed to constrain
connectivity (root to leaves, and leaves to root only) when switches connectivity (root to leaves, and leaves to root only) when switches
also support shared VLAN learning (or SVL). This would be consistent also support shared VLAN learning (or SVL). This would be consistent
with the root as a point of failure. with the root as a point of failure.
A 3. OAM Aspects A.3 OAM Aspects
Robustness is enhanced with the addition of data plane OAM to Robustness is enhanced with the addition of data plane OAM to provide
provide both fault and performance management. both fault and performance management.
For the configured VID/DMAC unicast mode of behavior, the hardware For the configured VID/DMAC unicast mode of behavior, the hardware
performs unicast packet forwarding of known MAC addresses exactly as performs unicast packet forwarding of known MAC addresses exactly as
Ethernet currently operates. The OAM currently defined, [802.1ag and Ethernet currently operates. The OAM currently defined, [802.1ag and
Y.1731] can also be reused without modification of the protocols. Y.1731] can also be reused minor modification of the protocols.
However currently if the VID for PBB-TE is different in each
direction some modification of the OAM may be required.
An additional benefit of domain wide path identifiers, for data An additional benefit of domain wide path identifiers, for data plane
plane forwarding, is the tight coupling of the 60 bit unique forwarding, is the tight coupling of the 60 bit unique connection ID
connection ID (VID/DMAC) and the associated OAM packets. It is a (VID/DMAC) and the associated OAM packets. It is a simple matter to
simple matter to determine a broken path or misdirected packet since determine a broken path or misdirected packet since the unique
the unique connection ID cannot be altered on the Eth-LSP. This is connection ID cannot be altered on the Eth-LSP. This is in fact one
in fact one of the most powerful and unique aspects of the domain of the most powerful and unique aspects of the domain wide label for
wide label for any type of rapid diagnosis of the data plane faults. any type of rapid diagnosis of the data plane faults. It is also
It is also independent of the control plane so it works equally well independent of the control plane so it works equally well for
for provisioned or GMPLS controlled paths. provisioned or GMPLS controlled paths.
Bidirectional transactions (e.g. ETH-LB) and reverse direction Bidirectional transactions (e.g. ETH-LB) and reverse direction
transactions MAY have a different VID for each direction. PBB-TE is transactions MAY have a different VID for each direction. PBB-TE is
specifying this aspect of CFM. specifying this aspect of CFM.
For configured multicast VID/DMAC mode, the current versions of For configured multicast VID/DMAC mode, the current versions of
802.1ag and Y.1731] make no representation as to how PDUs which are 802.1ag and Y.1731] make no representation as to how PDUs which are
not using unicast addresses or which use OAM reserved multicast not using unicast addresses or which use OAM reserved multicast
addresses are handled. Therefore this specification makes no addresses are handled. Therefore this specification makes no
representation as to whether such trees can be instrumented. representation as to whether such trees can be instrumented.
When configured VID mode of operation is used PBB-TE can be forced When configured VID mode of operation is used PBB-TE can be forced to
to use the same VID in both directions, emulating the current use the same VID in both directions, emulating the current Ethernet
Ethernet data plane and the OAM functions as defined in the current data plane and the OAM functions as defined in the current versions
versions of 802.1ag and Y.1731 can be used with no restriction. of 802.1ag and Y.1731 can be used with no restriction.
A 4. QOS Aspects A.4 QOS Aspects
Ethernet VLAN tags include priority tagging in the form of the Ethernet VLAN tags include priority tagging in the form of the PCP
802.1p priority bits. When combined with configuration of the paths priority bits. When combined with configuration of the paths via
via management or control plane, priority tagging produces the management or control plane, priority tagging produces the Ethernet
Ethernet equivalent of an MPLS-TE E-LSPs [RFC3270]. Priority tagged equivalent of an MPLS-TE E-LSPs [RFC3270]. Priority tagged Ethernet
Ethernet PDUs self-identify the required queuing discipline PDUs self-identify the required queuing discipline independent of the
independent of the configured connectivity. configured connectivity.
It should be noted that the consequence of this is that there is a It should be noted that the consequence of this is that there is a
common COS model across the different modes of configured operation common COS model across the different modes of configured operation
specified in this document. specified in this document.
The actual QOS objects required for signaling will be in a future The actual QOS objects required for signaling will be in a future
version of this memo. version of this memo.
A 5. Resiliency Aspects A.5 Resiliency Aspects
A 5.1. E2E Path protection A.5.1 E2E Path protection
One plus One(1+1) protection is a primary LSP with a disjoint One plus One(1+1) protection is a primary LSP with a disjoint
dedicated back up LSP. One for one (1:1) protection is a primary LSP dedicated back up LSP. One for one (1:1) protection is a primary LSP
with a disjoint backup LSP that may share resources with other LSPs. with a disjoint backup LSP that may share resources with other LSPs.
One plus One and One for One Automatic Protection Switching One plus One and One for One Automatic Protection Switching
strategies are supported. Such schemes offer: strategies are supported. Such schemes offer:
1) Engineered disjoint protection paths that can protect both 1) Engineered disjoint protection paths that can protect both
directions of traffic. directions of traffic.
2) Fast switchover due to tunable OAM mechanisms. 2) Fast switchover due to tunable OAM mechanisms.
3) Revertive path capability when primary paths are restored. 3) Revertive path capability when primary paths are restored.
4) Option for redialing paths under failure. 4) Option for redialing paths under failure.
Specific procedures for establishment of protection paths and Specific procedures for establishment of protection paths and
associating paths into "protection groups" are TBD. associating paths into "protection groups" are TBD.
Note that E2E path protection is able to respond to failures with a Note that E2E path protection is able to respond to failures with a
number of configurable intervals. The loss of CCM OAM frames in the number of configurable intervals. The loss of CCM OAM frames in the
data plane can trigger paths to switch. In the case of CCM OAM data plane can trigger paths to switch. In the case of CCM OAM
frames, the detection time is typically 3.5 times the CCM interval frames, the detection time is typically 3.5 times the CCM interval
plus the propagation delay from the fault. plus the propagation delay from the fault.
12. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
13. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Generated on: Mon Jul 14 00:52:55 EDT 2008
 End of changes. 145 change blocks. 
601 lines changed or deleted 548 lines changed or added

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