Technical Summary
This specification is complementary to the GMPLS Ethernet Label
Switching Architecture and Framework [RFC5828] and describes the
technology specific aspects of GMPLS control for Provider Backbone
Bridge Traffic Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary
GMPLS extensions and mechanisms are described to establish Ethernet
PBB-TE point to point (P2P) and point to multipoint (P2MP)
connections. This document supports, but does not modify, the
standard IEEE data plane.
Working Group Summary
Nothing of note.
Document Quality
There are no known implementations, but it is expected that several
vendors plan to implement.
Personnel
Deborah Brungard (db3546@att.com) is the Document Shepherd.
Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD.
RFC Editor Note
Section 4.1
OLD
Note, PBB-TE is designed to be bidirectional and symmetrically routed
just like Ethernet. That is, complete and proper functionality of
Ethernet protocols is only guaranteed for bidirectional Eth-LSPs. In
the following we discuss the establishment of bidirectional Eth-LSPs.
Note however that it is also possible to use RSVP-TE to configure
unidirectional ESPs, if the UPSTREAM_LABEL is not included in the
PATH message. To initiate a bidirectional Eth-LSP, the initiator
of the PATH message MUST use the procedures outlined in [RFC3473]
with the following specifics:
NEW
PBB-TE is designed to be bidirectional and symmetrically routed just
like Ethernet. That is, complete and proper functionality of Ethernet
protocols is only guaranteed for bidirectional Eth-LSPs. In this
section we discuss the establishment of bidirectional Eth-LSPs.
Note, however, that it is also possible to use RSVP-TE to configure
unidirectional ESPs, if the UPSTREAM_LABEL is not included in the
PATH message.
To initiate a bidirectional Eth-LSP, the initiator of the PATH
message MUST use the procedures outlined in [RFC3473] with the
following specifics:
END
---
Section 4.1.1
s/Eth LSP/Eth-LSP/
---
Section 5.1.2
OLD
The destination bridge after receiving the PATH message has to
allocate a VID, which together with its MAC address will constitute
the PBB-TE Ethernet Label. Depending on the size of the allocated
VLAN range and the number of Eth-LSPs terminated on a particular
bridge, it is possible that the available VIDs are exhausted and
hence no PBB-TE Ethernet Label can be allocated. In this case the
destination bridge SHOULD generate a PathErr message with error code:
Routing problem (24) and error value: MPLS Label allocation failure
(9).
NEW
The destination bridge after receiving the PATH message has to
assign a VID, which together with its MAC address will constitute
the PBB-TE Ethernet Label. An existing VID may be reused
when Shared forwarding is used or when there are no path conflicts
otherwise the bridge has to allocate a VID.
Depending on the size of the allocated VLAN range and the number of
Eth-LSPs terminated on a particular bridge, it is possible that the
available VIDs are exhausted and hence no PBB-TE Ethernet Label can
be allocated. In this case the destination bridge SHOULD generate a
PathErr message with error code: Routing problem (24) and error
value: MPLS Label allocation failure (9).
END
---
Section 5.2
OLD
IEEE defines a set of reserved MAC addresses Table 8-1 [IEEE 802.1Q]
that have special meaning, processing and follow specific forwarding
rules.
NEW
IEEE defines a set of reserved MAC addresses from 01-80-C2-00-00-00
to 01-80-C2-00-00-0F as explained in [IEEE 802.1Q] that have special
meaning, processing, and follow specific forwarding rules.
END
---
Section 6 Acronym expansions
UNI - User-to-Network Interface
NNI - Network-to-Network Interface
DOS - Denial of Service
---
Section 6
OLD
For a more comprehensive discussion on GMPLS security please see the
Security Framework for MPLS and GMPLS Networks[RFC5920].
Cryptography can be used to protect against many attacks described in
[RFC5920]. One option for protecting "transport" Ethernet is the use
of 802.1AE Media Access Control Security, [MACSEC] which provides
encryption and authentication."
NEW
Where control plane communications are point-to-point over links that
employ 802.1AE Media Access Control Security [MACSEC], it may
reasonably determined that no further security measures are used. In
other cases, it is appropriate to use control plane security where it
is deemed necessary to secure the signaling messages. GMPLS signaling
security measures are described in [RFC3471] and [RFC3473], and
inherit security techniques applicable to RSVP-TE as described in
[RFC3209] and [RFC2205]. For a fuller overview of GMPLS security
techniques see [RFC5920].
END
---
Section 7
DELETE
- Assign a new globally defined error value: "PBB-TE Ethernet Label
VID allocation failure" (suggested value: 35?) under the
"Routing problem" (24) error code in the RSVP Parameters / Error
Codes and Globally-Defined Error Value Sub-Codes registry.
END
---
Section 7
OLD
- Assign a new type from the Attributes TLV Space in the RSVP-TE
Parameters registry (suggested value 2) for the Service ID TLV
that is carried in the LSP_ATTRIBUTES Object (class = 197, C-Type
= 1) [RFC5420].
NEW
- Assign a new type from the Attributes TLV Space in the RSVP-TE
Parameters registry (suggested value 2) for the Service ID TLV
that is carried in the LSP_ATTRIBUTES Object (class = 197, C-Type
= 1) [RFC5420]. Please reocrd this new type as follows:
Name: I-SID Association TLV
Allowed on LSP_ATTRIBUTES Yes
Allowed on LSP_REQUIRED_ATTRIBUTES No
END
---
Section 8.1
ADD
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification", RFC 2205, September 1997.
---
Section 8.1
[RFC4872] Lang, J. et.al., "RSVP-TE Extensions in support of
End-to-End Generalized Multi-Protocol Label Switching
(GMPLS)-based Recovery", RFC 4871, May 2007.
s/4871/4872/
---
IANA Note
IANA: Please note the two RFC Editor note changes to Section 7.