One document matched: draft-fedyk-gmpls-ethernet-pbb-te-00.txt
Network Working Group Don Fedyk, David Allan, Nortel
Internet Draft Greg Sunderwood, Bell Canada
Category: Standards Track Himanshu Shah, Ciena
Nabil Bitar, Verizon
Attila Takacs, Diego Caviglia, Ericsson
Alan McGuire, BT
February 2007
GMPLS control of Ethernet
draft-fedyk-gmpls-ethernet-pbb-te-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire in August 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Carrier Grade Ethernet transport solutions require the capability of
flexible service provisioning and fast protection switching.
Currently, Ethernet is being extended in IEEE to meet the scalability
needs of transport networks.
The IETF specified GMPLS to control transport networks. To enable
integration of Ethernet based transport solutions the extension of
GMPLS control plane for Ethernet is of value.
Fedyk et.al Expires August 2007 Page 1
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
This memo describes how a GMPLS control plane may be applied to the
Provider Backbone Bridges Traffic Engineering (PBB-TE) amendment to
802.1Q and how GMPLS can be used to configure VLAN-aware Ethernet
switches in order to establish Ethernet P2P and P2MP MAC switched
paths and P2P/P2MP VID based trees. This document assumes any
standard changes to IEEE data planes will be undertaken only in the
IEEE.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Document History
This document has under gone name changes to follow the
standardization of Provider Backbone Bridges and the Traffic
engineering capability.
The original draft was:
draft-fedyk-gmpls-ethernet-ivl-00.txt.
This draft was renamed to reflect the Provider Backbone Transport
(PBT) nomenclature to:
draft-fedyk-gmpls-ethernet-pbt-00.txt
This draft was then edited to:
draft-fedyk-gmpls-ethernet-pbt-01.txt
At present the standardization of PBT is called Provider Backbone
Bridges Traffic Engineering (PBB-TE) and we have once again aligned
the documents naming to this present draft.
draft-fedyk-gmpls-ethernet-pbb-te-00.txt
Fedyk et al. Expires August 2007 Page 2
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
Table of Contents
1. Introduction...................................................5
2. Terminology....................................................5
3. GMPLS Control of PBB-TE Path creation and maintenance..........6
3.1 Using a GMPLS Control Plane for Ethernet.....................7
3.2 Control Plane Network........................................7
3.3 Point to Point Signaling.....................................8
3.3.1 Shared Forwarding...........................................9
3.4 Point to Multipoint Signaling...............................10
3.5 Ethernet Label..............................................10
3.6 Ethernet Service............................................11
3.7 GMPLS Link Management.......................................12
3.8 GMPLS Routing...............................................12
3.9 Path Selection..............................................12
3.9.1 Combinations of GMPLS Features.............................12
3.10 Addresses, Interfaces, and Labels..........................13
4. Specific Procedures...........................................14
4.1 PT to PT connections........................................14
4.1.1 P2P connections with shared forwarding.....................15
4.1.2 Dynamic P2P symmetry with shared forwarding................15
4.1.3 Planned P2P symmetry.......................................16
4.1.4 Path Maintenance...........................................16
4.2 P2MP VID/DMAC Connections...................................16
4.2.1 Setup procedures...........................................16
4.2.2 Maintenance Procedures.....................................16
4.3 P2P/P2MP VID Trees..........................................17
4.3.1 Setup Procedures...........................................17
4.3.2 Maintenance procedures.....................................17
4.4 OAM MEP ID and MA ID synchronization........................18
4.5 Protection Paths............................................18
5. Error conditions..............................................18
5.1 Invalid VID value for configured VID/DMAC range.............19
5.2 Invalid VID value for configured VID range..................19
5.3 Invalid MAC Address.........................................19
5.4 Invalid ERO for Upstream Label Object.......................19
5.5 Invalid ERO for Suggested Label Object......................19
5.6 Switch is not SVL capable...................................19
5.7 Invalid VID in upstream label object........................19
6. Deployment Scenarios..........................................19
7. Security Considerations.......................................19
8. IANA Considerations...........................................20
9. References....................................................20
9.1 Normative References........................................20
9.2 Informative References......................................20
10. Author's Address............................................21
11. Intellectual Property Statement.............................22
12. Disclaimer of Validity......................................23
13. Copyright Statement.........................................23
14. Acknowledgments.............................................23
Appendix A.......................................................24
A 1. Aspects of configuring Ethernet Forwarding.................24
Fedyk et al. Expires August 2007 Page 3
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
A 2. Overview of configuration of VID/DMAC tuples...............26
A 3. Overview of configuration of VID port membership...........29
A 4. OAM Aspects................................................29
A 5. QOS Aspects................................................30
A 6. Resiliency Aspects.........................................30
A 6.1 E2E Path protection.......................................30
Fedyk et al. Expires August 2007 Page 4
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
1. Introduction
Ethernet switches are increasing in capability. As a consequence the
role of Ethernet is rapidly expanding in networks that were the
domain of other technologies such as SONET/SDH TDM and ATM. The
question of how Ethernet will evolve and what capabilities it can
offer in these areas is still under development.
The various standards bodies are responding to the strong demands by
the operators for making the Ethernet a carrier-class transport
solution. Following is a short list of major activities in different
standards organization,
- IEEE 802.1Q is amending VLAN-aware bridges to handle scalability
and service provisioning needs of the operators
- IEEE 802.1ad, Provider Bridges and 802.1ah Provider Backbone
Bridges are developed to provide hierarchical solution to handle
scalability
- IEEE 802.1ag, Connectivity Fault Management is improving bridge
functionalities to provide fault management and performance
monitoring for Ethernet networks
- ITU-T Y.1731 is specifying extensive OAM capabilities for
Ethernet
- G.8031 is defining protection switching in Ethernet based on
CFM's continuity check protocol. This standard provides p2p
VLAN-based Ethernet paths configurations at head and tail end
for working and protection traffic.
- IEEE 802.1 is embarking on Traffic Engineered Ethernet paths in
the Provider Backbone Bridged network (PBB-TE) based on managed
objects that can be statically configured and no changes to
Ethernet data plane.
The main purpose of this document is to specify a GMPLS based
control plane for PBB-TE.
2. Terminology
In addition to well understood GMPLS terms, this memo uses
terminology from IEEE 802.1 and introduces a few new terms:
B-MAC Backbone MAC
B-VID Backbone VLAN ID
B-VLAN Backbone VLAN
COS Class of Service
C-MAC Customer MAC
C-VID Customer VLAN ID
C-VLAN Customer VLAN
DMAC Destination MAC Address
LLDP Link Layer Discovery Protocol
Fedyk et al. Expires August 2007 Page 5
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
MAC Media Access Control
MP2MP Multipoint to multipoint
PBB Provider Backbone Bridges
PBB-TE Provider Backbone Bridges Traffic Engineering
P2P Point to Point
P2MP Point to Multipoint
QOS Quality of Service
SMAC Source MAC Address
S-VID Service VLAN ID
SVL Shared VLAN Learning
VID VLAN ID
VLAN Virtual LAN
3. GMPLS Control of PBB-TE Path creation and maintenance
PBB-TE is an Ethernet connection oriented technology, being
specified in the IEEE, which can be controlled by configuration of
static filtering entries [see Appendix A]. PBB-TE paths are created
switch by switch by simple configuration of Ethernet logical ports
and assignment of PBB-TE labels. We term a PBB-TE path as a form of
Ethernet LSP (Eth-LSP). PBB-TE paths may be configured by command
line interface on the switches or coordinated from a management
system. This memo proposes GMPLS as a mechanism to automate set-up
tear down and recovery of PBB-TE paths.
The advantages of using GMPLS over simple provisioning are,
- Reduction in number of configuration commands
- Improvement in the coordination of commands that are required to
establish and maintain an ETH-LSP
- Capability to automate the dynamic modification of parameters
- On-net/off-net path computations
- Automatic reaction to network changes without manual
intervention
PBB-TE uses the Ethernet data plane in its native form. When
configuring a PBB-TE path with GMPLS, the DMAC and VID are carried
in a generalized label object and are assigned hop by hop but are
invariant within a domain. PBB-TE paths are composed of uni-
directional Eth-LSPs that are paired together. The DMAC must be
different in the two LSPs. The VID may be the same or different in
each direction as it is only used, from a data plane perspective, to
identify the path co-jointly with the DMAC. To be consistent with
GMPLS terminology, PBB-TE paths are created first as an explicit
route object (ERO) and data plane labels are assigned from the
available label pool at the destination switch. Each PBB-TE label is
a domain wide unique label, the VID/DMAC, for each direction.
Several attributes may be associated with an Eth-LSP, including:
Fedyk et al. Expires August 2007 Page 6
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
- bandwidth requirements of the path. This can be used, for example,
to request a fixed bandwidth path, where the committed information
rate and peak information rate have the same value.
- priority level;
- preemption characteristics;
- protection/resiliency requirements;
- routing policy, such as an explicit route;
- policing requirements
Note GMPLS currently does not support asymmetrical attributes in
each direction for a bidirectional LSP. GMPLS control of PBB-TE
should allow these parameters to be specified independently.
In addition to the above policies based on either under-subscription
or over-subscription can be supported.
3.1 Using a GMPLS Control Plane for Ethernet
GMPLS [RFC3495] has been adapted to the control of SDH/Sonet and
optical switches for the purpose of managing optical paths. GMPLS
signaling is well suited to setup paths with labels but it does
require an IP control plane and IP connectivity.
In many Ethernet deployment situations, the addition of a complete
GMPLS control plane may be excessive for the switch technology or
the network application. For this reason we consider partial
application of GMPLS whereby either complete functionality applied
to a subset of the switches and/or partial functionality applied to
some or all switches. For discussion purposes, we decompose the
problem of applying GMPLS into the functions of Signaling, Routing,
Link Management and Path Selection. We can use some functions of
GMPLS alone or in partial combinations. In most cases using all
functions of GMPLS incurs less operational overhead than any partial
combinations. In fact, using only some components of GMPLS may cause
more provisioning overhead for some objects than a purely static
system (see "Combinations of GMPLS Features").
3.2 Control Plane Network
In order to have a GMPLS control plane, an IP control plane
consisting of an IGP with TE extension needs to be established. This
IGP views each hop as a terminated IP adjacency and should not be
interpreted as a distinct routed subnet for the purpose of carrying
IP bearer traffic. In other words IP is the control plane but the
forwarding plane is not IP.
This IP control plane can be provided as a separate independent
network (out of band) or integrated with the Ethernet switches.
If the IP control plane is a separate network, it may be provided as
a Layer 2 connected LAN where the Ethernet switches are connected
Fedyk et al. Expires August 2007 Page 7
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
via a bridged network or HUB. It may also be provided by an
external network that provides IP connectivity but in this case, the
control topology of the GMPLS/Ethernet switches may not be the same
topology as the physical data plane network.
If the IP control plane is integrated with the switches it may be
provided by a bridged VLAN that uses the Data bearing channels of
the network between adjacent nodes. This ties the fate of the
controlled paths and the IP control plane links, which is not unlike
the situation with MPLS networks or even some GMPLS optical
networks.
3.3 Point to Point Signaling
GMPLS signaling is well suited to the application of PBB-TE on
Ethernet switches. GMPLS signaling uses either numbered or
unnumbered links where the link is either explicitly IP addressed or
associated with a switch loopback address. If LMP [RFC4204] is used,
the creation of these unnumbered interfaces can be automated. If LMP
is not used there is an additional provisioning requirement to add
GMPLS link identifiers. For large-scale implementations LMP would be
beneficial. As mentioned earlier, the primary benefit of signaling
is the control of a path from an endpoint. GMPLS can be used to
create bi-directional or unidirectional paths, bi-directional paths
being the preferred mode of operation for numerous reasons (OAM
consistency etc.). In this document we only consider bidirectional
paths that share the same route/resources both for P2P and P2MP
services.
Signaling enables the ability to dynamically establish a path and to
adjust the path in a coordinated fashion after the path has been
established. Signaling also improves multi-vendor interoperability
over simple management since the signaling is standard and handles a
number of dynamic functions. This allows the network to adapt to
changing conditions or failures with a single mechanism. Signaling
can be used for pure static configured paths as well.
To use GMPLS RSVP-TE signaling a few modifications are required. A
new label is defined that contains the VID/DMAC tuple. On the
initiating and terminating nodes, a function administers the VIDs
associated with the SMAC and DMAC respectively. PBB-TE is designed
to be bidirectional and symmetric just like Ethernet. Therefore in
PBB-TE, the packet SMAC and DMAC pair is same in the forwarding path
and the associated reverse path except they are flipped in the
reverse direction. .
To initiate a bi-directional VID/DMAC P2P or P2MP path, the
initiator of the PATH message uses procedures outlined in [GMPLS-
SIGNALING] possibly augmented with [MPLS-P2MP], it:
1) Sets the LSP encoding type to Ethernet.
2) Sets the LSP switching type to MAC [IANA to define].
Fedyk et al. Expires August 2007 Page 8
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
3) Sets the GPID to Unknown (1) or Ethernet Multiplexed [IANA to
define].
4) Sets the UPSTREAM_LABEL to the VID/SMAC tuple where the VID is
administered from the configured VID/DMAC range. Downstream switches
must use the SUGGESTED LABEL or return a Path Error condition
indicating why the label could not be used. Alternatively, if the
optional LABEL SET object is implemented, the upstream switches can
use this to specify the required label.
At intermediate switches the UPSTREAM_LABEL object and value is
passed unmodified. The VID/SMAC tuple is used to create a static
forwarding entry in the Filtering Database of bridges at each hop
for the upstream direction. The port derived form the ERO and the
VID and DMAC included in the label constitute the static entry.
At the destination, a VID is allocated in the local MAC range for
the DMAC and the VID/DMAC tuple is passed in the GENERALIZED_LABEL
in the RESV message. As with the UPSTREAM_LABEL, intermediate
switches use the GENERALIZED_LABEL object and pass it on unchanged,
upstream. The VID/DMAC tuple is installed in the forwarding table
at each hop. This creates a bi-directional path as the PATH and RESV
messages follow the same path.
3.3.1 Shared Forwarding
One capability of a connectionless Ethernet data plane is to reuse
destination forwarding entries for packets from any source within a
VLAN to a destination. When setting up point to point PBB-TE
connections for multiple sources sharing a common destination this
capability can be preserved provided certain requirements are met.
We refer to this capability as Shared Forwarding. Shared forwarding
is invoked based on policy when conditions are met. It is a local
decision by label allocation at each end. Shared forwarding has no
impact on the actual paths setup, but it allows the reduction of
forwarding entries.
To achieve shared forwarding, a Path computation engine should
ensure the ERO is consistent with an existing path for the shared
segments. If a path satisfies the consistency check, the upstream
end of the signaling may chose to share an existing VID/DMAC for the
upstream traffic with an existing Eth-LSP. 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 hops consecutively. Once
the paths diverge they must remain divergent. If no existing path
has this behavior when a new path is being created the new path will
be created unshared either by using another VID or another DMAC or
both.
In other words, shared forwarding is possible when paths share
segments either from the source or the destination. For the source,
the upstream label is chosen to be the same as an existing path.
Fedyk et al. Expires August 2007 Page 9
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
Similarly for the destination, shared forwarding is possible when an
existing path that shares segments with the new paths ERO, viewed
from the destination switch. The downstream label in this case is
chosen to be the same as the existing path. In this manner shared
forwarding is a function that is controlled primarily by policy and
in combination with the local label allocation at the end points of
the path.
3.4 Point to Multipoint Signaling
To initiate a P2MP VID path the initiator of the PATH message uses
procedures outlined in [GMPLS-SIGNALING] and [MPLS-P2MP]. A P2MP
tree consists of a VID or Mulitcast tree in the forward direction
(from root to leaves) and a set of P2P paths running on identical
paths from Tree to root in the reverse direction. VID/DMAC labels
with a single Multicast DMAC address are allocated in the forward
direction and a single VID/DMAC label in the reverse direction:
1) Sets the LSP encoding type to Ethernet.
2) Sets the LSP switching type to L2SC.
3) Sets the GPID to unknown.
4) Set the technology specific information in the TSPEC to indicate
a domain-wide label.
5) Sets the UPSTREAM LABEL specified as a single VID/DMAC from the
configured VID range.
6) VID translation may optionally be permitted on a local basis
between two switches by a downstream switch replying with a VID/DMAC
other than the SUGGESTED LABEL. 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.
3.5 Ethernet Label
The Ethernet label is a new generalized label with a suggested
format of:
Fedyk et al. Expires August 2007 Page 10
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| VLAN ID | MAC (highest 2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the new label type for a non-zero MAC address is
that that the label is passed unchanged. This label is a domain wide
label. This has similarity to the way in which a wavelength label
is handled at an intermediate switch that cannot perform wavelength
conversion, and is described in [GMPLS-RSVP].
These domain wide labels are allocated to switches that control the
assignment of labels. There are two options for Ethernet MAC based
domain wide unique labels. One option is to allocate the DMACs from
globally unique addresses assigned to the either the switch
manufacturer or the owner. The other option is to use DMACs out of
the local admin space and ensue these labels are unique within the
domain. This local DMAC space does not have to be globally unique
because the labels are only valid within a single provider domain.
In the case of local label allocation there is less administrative
overhead to allocate labels. However when using configuration, a
tool would have to perform a consistency check to make sure that
label terminations were unique. When using GMPLS signaling it is
assumed a unique pool of labels would be assigned to each switch.
The DMAC addresses are domain wide unique and so is the combination
of VID/DMAC. It is intended that the VID/DMAC be only used by one
destination. However, should an error occur and a somehow a
duplicate label be assigned to one or more destination switches
GMPLS signaling procedures would allow the first assignment of the
label and prevent any duplicate label from colliding. If a collision
occurs an alarm would be generated. In fact some of these procedures
have been defined in GMPLS control of photonic networks where a
lambda may exist as a form of domain wide label.
3.6 Ethernet Service
Ethernet Switched Paths that are setup either by configuration or
signaling can be used to provide an Ethernet service to customers of
the Ethernet network. The Metro Ethernet Forum has defined some
services in MEF.6 (e.g., Ethernet Private Line), and these are also
aligned with ITU-T G.8011-x Recommendations. Of particular interest
are the bandwidth profile parameters in MEF.10 and whose associated
bandwidth profile algorithm are based on [RFC4115][RFC3270].
Consideration should be given to supporting these in any signaling
extensions for Ethernet LSPs. This will be addressed in a future
version of this specification.
Fedyk et al. Expires August 2007 Page 11
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
3.7 GMPLS Link Management
Link discovery is one of the building blocks of GMPLS. It is also a
capability that has been specified for Ethernet in IEEE 802.1AB.
Link discovery is optional but the benefits of running link
discovery in large systems are significant. Link discovery reduces
configuration and the possibility of errors in configuration as well
as exposing misconnections. It is likely that a standard Ethernet
implementation would have 802.1AB functions. A recommendation is
that standard 802.1AB could be run with an extension to feed
information into an LMP [RFC4204] information model. LMP is a
superset capability while 802.1AB has certain capabilities just for
Ethernet. See Figure 3.
+---------+ +---------+
| | | |
| LMP | ----------| LMP |
| +-------+ IP (opt) +-------+ |
| |802.1AB| ----------|802.1AB| |
+-+-------+ Ethernet +-------+-+
Figure 3 Link Discovery Hierarchy
3.8 GMPLS Routing
GMPLS routing [GMPLS-ROUTING] is IP routing with the opaque TLV
extensions for the purpose of carrying around GMPLS TE information.
The TE information is populated with TE resources from coordinated
with LMP or from configuration if LMP is not available. The
bandwidth resources of the links are tracked as Eth-LSPs are set up.
GMPLS Routing is an optional piece but it is highly valuable in
maintaining topology and distributing the TE database for path
management and dynamic path computation.
3.9 Path Selection
There has been a lot of recent activity in the area of path
computation [PATH-COMP] and selection. Originally MPLS path
computation was performed locally in a TE database of a router.
While this is non-optimal for situations where bandwidth is highly
managed, it was acceptable when a few paths were required in a
primarily connectionless environment; if a large number of
coordinated paths are required, it is advantageous to have a more
sophisticated path computation engine capable of optimizing the path
routing of a sub network. The path computation could take the form
of paths being computed either on a management station with local
computation for rerouting or more sophisticated path computation
servers.
3.9.1 Combinations of GMPLS Features
Fedyk et al. Expires August 2007 Page 12
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
The combinations of LMP, Routing, Signaling and Path computation can
be all supported on a switch or a subset of GMPLS features can be
supported.
Signaling is the minimal function that might be supported on a small
switch. The ability to process Signaling messages with an ERO may be
all that is desired on an end point. In this case the path
computation would be performed off network.
Routing for GMPLS is the next important function since it provides
the forwarding of signaling functions and transport of TE
information. There is no requirement to provide full IP routing for
data traffic, only hop by hop routing for the control plane. However
it is possible to design switches without routing that could proxy
their routing to other larger switches. In the proxied case, there
would be little difference in the routing database but the small
switches would not have to perform routing operations. The
information for the proxied routing might be configured or it might
be data filled by an automated procedure. No new protocols are
envisioned for the case where routing is proxied.
LMP is optional. The primary benefit of LMP in addition to 802.1AB
is LMP's capability to optimize routing information for the purpose
of link bundling on large switches. LMP has the capability to
compress the information required to represent a large number of
parallel resources automatically and reduce the amount of
configuration.
3.10 Addresses, Interfaces, and Labels
This specification uses an addressing scheme and a label space for
the ingress/egress connection; the hierarchical TE Router
ID/Interface ID and the Ethernet VID/DMAC tuple or VID/Multicast MAC
as a label space.
TE Router ID
|
V N=named port
+----+ +-----+ <port index>
| | label=VID/DMAC | | <MAC>
| PB | label=VID/MMAC | | <string>
-----N N----------------------------N PBB N----------
| | |(MAC)| \
| | / | Customer
+----+ /+-----+ Facing
PBB-TE Transit Provider MAC PBB-TE edge Ports
Switch Switch
Figure 4 Ethernet/GMPLS Addressing & Label Space
Fedyk et al. Expires August 2007 Page 13
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
Depending on how the service is defined and set up one or more of
these identifiers may be used for actual setup. An Ethernet port name
is common to both configured VID/DMAC, configured VID and bridging
modes of operation.
For a GMPLS based system, the TE Router ID/logical port is the
logical signaling identifier for the control plane via which Ethernet
layer label bindings are solicited. In order to create a point to
point path an association must be made between the ingress and egress
node. But the actual label distributed via signaling and
instantiated in the switch forwarding tables identifies the upstream
and downstream egress VID/DMAC of the PBB-TE path (see Figure 4).
GMPLS uses un-numbered identifiers in the form of 32 bit numbers
which are in the IP address notation but are not IP addresses. An IP
routing control plane for the propagation of TE information may be
supported. The provider MAC port addresses are exchanged by the LLDP
and by LMP if supported. However these identifiers are merely for
link control and legacy Ethernet support and have local link scope.
Actual label assignment is performed by the signaling initiator and
terminator.
A particular port on a provider network switch would have:
- A VID/DMAC
- A 32 bit IPv4 Switch address or 128 bit IPv6 address plus 32 bit
interface Identifier
- One (or more) Mnemonic String Identifiers
This multiple naming convention leaves the issue of resolving the set
given one of the port identifiers. On a particular node, mapping is
relatively straightforward. The preferred solution to this is to use
the GMPLS IP switch address for signaling resolution. In so doing,
the problem of setting up a path is reduced to figuring out what
switch supports an egress MAC address and then finding the
corresponding GMPLS IP switch address and performing all signaling
and routing with respect to the TE Router ID.
There are several options to achieve this:
- Provisioning
- Auto discovery protocols that carry MAC address
- Augmenting Routing TE with MAC Addresses
- Name Servers with identifier/address registration
The specific procedures will be clarified in a subsequent version of
this document.
4. Specific Procedures
4.1 PT to PT connections
The Data Plane for Ethernet has three key fields: VID, DMAC and SMAC.
A connection instance is uniquely identified, in the data plane, by
the DMAC, the VID and the SMAC for the purpose of the provider
Fedyk et al. Expires August 2007 Page 14
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
network terminations. From a GMPLS control plane point of view an
Ethernet LSP is also identified as any other LSP using the 5-tuple
[Ip_Source_Sddr, Ip_Dest_Addr, LSP_Id, Tunnel_ID,
Extended_Tunnel_ID]. The VID and DMAC tuple identifies the forwarding
multiplex at transit switches and a simple degenerate form of the
multiplex is P2P (only one VID/DMAC/SMAC connection uses the VID/DMAC
tuple).
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
allowing the connection to be de-multiplexed downstream.
4.1.1 P2P connections with shared forwarding
The VID/DMAC can be considered to be a shared forwarding identifier
or label for a multiplex consisting of some number of P2P connections
distinctly identified by the MAC VID/DMAC/SMAC tuple. The reason for
using a shared forwarding entry is it reuses existing labels and
forwarding hardware. In some ways this is analogous to an LDP label
merge but in the shared forwarding case only the forwarding entry is
reused.
VLAN tagged Ethernet packets include priority marking. Priority bits
can be used to indicate class of Service (COS) and drop priority.
Thus, traffic from multiple COSs could be multiplexed on the same ESP
(i.e., similar to E-LSPs) and queuing and drop decisions are made
based on the p-bits. This means that the queue selection can be done
based on a per flow (i.e., ESP + priority) basis and is decoupled
from the actual steering of the packet at any given node.
A switch terminating an ESP will frequently have more than one
suitable candidate path and it may choose to share a forwarding
entry.(common VID/DMAC , unique SMAC). It is a local decision of how
this is performed but the best choice is a path that maximizes the
shared forwarding.
The concept of bandwidth management still applies equally well with
shared forwarding. As an example consider a PBB-TE edge switch that
terminates an Ethernet LSP with the following attributes: bandwidth
B1, DMAC D, SMAC S1, VID V. A request to establish an additional
Ethernet LSP with attributes (bandwidth B2, DMAC D, SMAC S2, VID V)
can be accepted provided there is sufficient link capacity remaining.
4.1.2 Dynamic P2P symmetry with shared forwarding
Similar to how a destination switch may select a VID/DMAC from the
set of existing shared forwarding multiplexes rooted at the
destination node, the originating switch may also do so for the
reverse path. Once the initial ERO has been computed and the set of
existing Ethernet LSPs that include the target DMAC have been pruned,
the originating switch may select the optimal (by whatever criteria)
existing shared forwarding multiplex for the new destination to merge
Fedyk et al. Expires August 2007 Page 15
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
with and offer its own VID/DMAC tuple for itself as a destination.
This is identified via use of the UPSTREAM LABEL object.
4.1.3 Planned P2P symmetry
Normally the originating switch will not have knowledge of the set of
shared forwarding paths rooted on the destination node.
Use of a Path Computation Server or other planning style of tool with
more complete knowledge of the network configuration may wish to
impose pre-selection of shared forwarding multiplexes to use for both
directions. In this scenario the originating switch uses the
SUGGESTED LABEL and UPSTREAM LABEL objects to indicate complete
selection of the shared forwarding multiplexes at both ends. This may
also result in the establishment of a new VID/DMAC path as the
SUGGESTED LABEL object may legitimately refer to a path that does not
yet exist.
4.1.4 Path Maintenance
Make before break procedures can be employed to modify the
characteristics of a P2P Ethernet LSP. As described in [RFC3209],
the LSP ID in the sender template is updated as the new path is
signaled. The procedures (including those for shared forwarding) are
identical to those employed in establishing a new LSP, with the
extended tunnel ID in the signaling exchange ensuring that double
booking of the associated resources does not occur.
Where individual paths in a protection group are modified, signaling
procedures may be combined with Protection Switching (PS)
coordination to administratively force PS switching operations such
that modifications are only ever performed on the protection path.
4.2 P2MP VID/DMAC Connections
4.2.1 Setup procedures
The group DMAC is administered from a central pool of multicast
addresses and the VLAN selected from the configured VID/DMAC range.
The P2MP tree is constructed via incremental addition of leaves to
the tree in signaling exchange where the root is the originating
switch (as per (MPLS-P2MP). The multicast VID/DMAC are encoded in the
suggested label object using the Ethernet label encoding.
Where a return path is required the unicast MAC corresponding to the
originating interface and a VID selected from the configured VID/DMAC
range is encoded as an Ethernet label in the upstream label object.
4.2.2 Maintenance Procedures
Maintenance and modification to a P2MP tree can be achieved by a
number of means. The preferred technique is to modify existing VLAN
Fedyk et al. Expires August 2007 Page 16
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
configuration vs. assignment of a new label and completely
constructing a new tree.
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
traffic is forced on the working tree and locked (PS not allowed)
while the backup tree is modified. Explicit path tear of leaves to
be modified is required to ensure no loops are left behind as
artifacts of tree modification. Once modifications are complete, a
forced switch to the backup tree occurs and the original tree may be
similarly modified. This also suggests that 1+1 or 1:1 resilience
can be achieved for P2MP trees for any single failure (switch on any
failure and use restoration techniques to repair the failed tree).
4.3 P2P/P2MP VID Trees
4.3.1 Setup Procedures
The VID is administered from the central pool of VLAN IDs
corresponding to the configured VID range. The P2MP VID tree is
constructed via incremental addition of leaves to the tree in
signaling exchange where the root is the originating switch as per
[MPLS-P2MP].
Where (*,*) connectivity is to be configured a single VID is employed
and encoded as an Ethernet label in the suggested label object with
MAC address set to zero.
Where communication is to be constrained to root to leaves and leaves
to root only, asymmetrical VID configuration is used with the
suggested label object encoding the root to leaf VID and the upstream
label object encoding the leaf to root VID.
4.3.2 Maintenance procedures
Maintenance and modification to a P2P or P2MP VID tree can be
achieved by a number of means. The preferred technique being to move
traffic off the tree, modify the tree and then shift traffic back to
the tree. This ensures that there are no transient loops in the tree
that are artifacts of interactions of the GMPLS control plane, soft
state and the Ethernet data plane.
Make before break on a live tree 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) while the backup tree is modified.
Explicit path tear of leaves to be modified is required to ensure no
loops are left behind as artifacts of tree modification. Once
modifications are complete, a forced switch to the backup tree
occurs and the original tree may be similarly modified. This also
suggests that 1+1 or 1:1 resilience can be achieved for P2MP trees
for any single failure (switch on any failure and use restoration
techniques to repair the failed tree).
Fedyk et al. Expires August 2007 Page 17
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
4.4 OAM MEP ID and MA ID synchronization
The Maintenance end point IDs (MEP IDs) and maintenance association
IDs for the switched path endpoints can be synchronized using the
ETH-MCC (maintenance communication channel) transaction set once the
switched path has been established.
MEPs are located at the endpoints of the Ethernet LSP. Typical
configuration associated with a MEP is Maintenance Domain Name,
Short Maintenance Association Name, and MA Level, MEP ID, and CCM
transmission rate (when ETH-CC functionality is desired). As part of
the synchronization, it is verified that the Maintenance Domain
Name, Short Maintenance Association Name, MA Level, and CCM
transmission rate are the same. It is also determined that MEP IDs
are unique for each MEP.
Server MEPs can be considered at the intermediate points of the PBB-
TE network. Upon network failures (e.g. physical link failures), the
Server MEPs can initiate the unicast AIS frames for each Ethernet
LSP end-point that is present in the forwarding table. The only
configuration required at the Server MEPs is the MA Level which
should be the same as the MA Level configured at the Ethernet LSP
MEPs.
Besides the unicast CCM and AIS functionality, the PBB-TE MEPs can
also offer the LBM/LBR and LMM/LMR functionalities for on-demand
connectivity verification and loss measurement purposes.
4.5 Protection Paths
When protection is used for path recovery it is required to
associate the working and protection paths into a protection group.
This is achieved as defined in [RECOVERY_SIG] using the ASSOCIATION
and PROTECTION objects. Protection may be used for P2P VID/DMAC,
P2MP VID/DMAC and P2P/P2MP VID configured modes of operation. The
'P' bit in the protection object indicates the role (working or
protection) of the LSP currently being signaled.
If the initiating switch wishes to use G.8031 [G-8031] data plane
protection switching coordination (vs. control plane notifications),
it sets the N bit to 1 in the protection object. This must be
consistently applied for all paths associated as a protection group.
If the terminating switch does not support G.8031, the error
"Admission Control Failure/Unsupported Notification Type" is used.
5. Error conditions
The following errors have been identified as being unique to these
procedures and in addition to those already defined. This will be
Fedyk et al. Expires August 2007 Page 18
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
addressed in a proper IANA considerations section in a future
version of the document:
5.1 Invalid VID value for configured VID/DMAC range
The originator of the error is not configured to use the VID value
in conjunction with GMPLS signaling of VID/DMAC tuples. This may be
any switch along the path.
5.2 Invalid VID value for configured VID range
5.3 Invalid MAC Address
The MAC address is out of a reserved range that cannot be used by
then node which is processing the address. While almost all MAC
addresses are valid there is a small number of reserved MAC
addresses.
5.4 Invalid ERO for Upstream Label Object
The ERO offered has discontinuities with the identified VID/DMAC
path in the UPSTREAM LABEL object.
5.5 Invalid ERO for Suggested Label Object
The ERO offered has discontinuities with the identified VID/DMAC
path in the SUGGESTED LABEL object.
5.6 Switch is not SVL capable
This error may arise only in P2MP VID Tree allocation.
5.7 Invalid VID in upstream label object
The VID in the upstream label object for the "asymmetrical VID"
P2MP tree did not correspond to the VID used in previous
transactions.
6. Deployment Scenarios
This technique of GMPLS controlled Ethernet switching is applicable
to all deployment scenarios considered by the design team [CCAMP-
ETHERNET].
7. Security Considerations
The architecture assumes that the GMPLS controlled Ethernet subnet
consists of trusted devices and that the UNI ports to the domain are
untrusted. Care is required to ensure untrusted access to the trusted
domain does not occur. Where GMPLS is applied to the control of VLAN
Fedyk et al. Expires August 2007 Page 19
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
only, the commonly known techniques for mitigation of Ethernet DOS
attacks may be required on UNI ports.
8. IANA Considerations
New values are required for signaling and error codes as indicated.
This section will be completed in a later version.
9. References
9.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[CCAMP-ETHERNET] Papadimitriou, D. et.al, "A Framework for
Generalized MPLS (GMPLS) Ethernet", internet draft, draft-
papadimitriou-ccamp-gmpls-ethernet-framework-00.txt , June 2005
[GMPLS-SIGNALING] Berger, L. (editor), "Generalized MPLS -Signaling
Functional Description", January 2003, RFC3471.
[GMPLS-ROUTING] Kompella, K., Rekhter, Y., "Routing Extensions in
Support of Generalized MPLS", RFC 4202, October 2005
[GMPLS-RSVP] Berger, L. et.al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", IETF RFC 3473, January 2003.
9.2 Informative References
[RFC4115] Aboul-Magd, O. et.al. "A Differentiated Service Two-Rate,
Three-Color Marker with Efficient Handling of in-Profile Traffic",
IETF RFC 4115, July 2005
[G-8031] ITU-T Draft Recommendation G.8031, Ethernet Protection
Switching.
[RFC3495] E. Mannie, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3495.
[IEEE 802.1AB] "IEEE Standard for Local and Metropolitan Area
Networks, Station and Media Access Control Connectivity
Discovery".
[IEEE 802.1ag] "IEEE Draft Standard for Connectivity Fault
Management", work in progress.
[IEEE 802.1ah] "IEEE standard for Provider Backbone Bridges", work in
progress.
Fedyk et al. Expires August 2007 Page 20
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
[RFC4204] Lang. J. Editor, "Link Management Protocol (LMP)" RFC4204,
October 2005
[MEF.6] The Metro Ethernet Forum MEF 6 (2004), "Ethernet Services
Definitions - Phase I".
[MEF.10] The Metro Ethernet Forum MEF 10 (2004), "Ethernet Services
Attributes Phase 1".
[RFC3270] Le Faucheur, F. et.al., "Multi-Protocol Label Switching
(MPLS) Support of Differentiated Services" IETF RFC 3270, May
2002.
[MPLS-P2MP] Aggarwal, R. Ed., "Extensions to RSVP-TE for Point to
Multipoint TE LSPs", work in progress.
[MYERS] Myers et.al. "Rethinking the service model, scaling Ethernet
to a million nodes", http://100x100network.org/papers/myers-
hotnets2004.pdf.
[PATH-COMP] Farrel, A. et.al., "Path Computation Element (PCE)
Architecture", work in progress.
[PWoPBT] Allan et.al., "Pseudo Wires over Provider Backbone
Transport", draft-allan-pw-o-pbt-02.txt, work in progress.
[RFC3985] Bryant, S., Pate, P. et al., "Pseudo Wire Emulation Edge-
to Edge (PWE3) Architecture", IETF RFC 3985, March 2005.
[RECOVERY_SIG] Lang et.al., "RSVP-TE Extensions in support of End-
to-End Generalized Multi-Protocol Label Switching (GMPLS)-based
Recovery ", work in progress.
[RFC3209] Awduche et.al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels, IETF RFC 3209, December 2001.
[Y.1731] ITU-T Draft Recommendation Y.1731(ethoam), " OAM Functions
and Mechanisms for Ethernet based Networks ", work in progress.
10. Author's Address
Don Fedyk
Nortel Networks
600 Technology Park Drive Phone: +1-978-288-3041
Billerica, MA, 01821 Email: dwfedyk@nortel.com
David Allan
Nortel Networks Phone: +1-613-763-6362
3500 Carling Ave. Email: dallan@nortel.com
Ottawa, Ontario, CANADA
Greg Sunderwood
Fedyk et al. Expires August 2007 Page 21
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
Bell Canada Phone: +1-604-648-7770
Suite 1500, Email: greg.sunderwood@gt.ca
1066 West Hastings Street
Vancouver, BC, CANADA
V6E 2X1
Himanshu Shah
Ciena Phone: 978-489-2196
35 Nagog Park, Email: hshah@ciena.com
Acton, MA 01720
Nabil Bitar Phone: (781) 466-2161
Verizon, Email: nabil.n.bitar@verizon.com
40 Sylvan Rd.,
Waltham, MA 02451
Attila Takacs
Ericsson
1. Laborc u.
Budapest, HUNGARY 1037 Email: attila.takacs@ericsson.com
Diego Caviglia Email: diego.caviglia@ericsson.com
Ericsson
Alan McGuire
BT Group PLC Phone: +44 1473 645010
OP6 Polaris House, Email: alan.mcguire@bt.com
Adastral Park,
Martlesham Heath,
Ipswich, Suffolk,
IP5 3RE, UK
11. Intellectual Property Statement
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.
Fedyk et al. Expires August 2007 Page 22
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
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 (2007).
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 extensive contributions to this
document.
Fedyk et al. Expires August 2007 Page 23
Appendix A
A 1. Aspects of configuring Ethernet Forwarding
Ethernet as specified today is a complete system consisting of a
data plane and a number of control plane functions. Spanning tree,
data plane flooding and MAC learning combine to populate forwarding
tables and produce resilient any-to-any behavior in a bridged
network.
Ethernet consists of a very simple and reliable data plane that has
been optimized and mass produced. By simply disabling some Ethernet
control plane functionality, it is possible to employ alternative
control planes and obtain different forwarding behaviors.
Customer Provider Provider
Bridge/ Bridge Backbone
Bridge
C-MAC/C-VID------------------802.1Q -------------------C-MAC-CVID
S-VID-----------802.1ad------------S-VID
B-MAC---802.1ah---B-MAC
B-VID---802.1ah---B-VID
Figure 1 802.1 MAC/VLAN Hierarchy
Recent works in IETF Pseudo Wire Emulation [RFC3985] and IEEE 802
are defining a separation of Ethernet functions permitting an
increasing degree of provider control. The result is that the
Ethernet service to the customer appears the same, yet the provider
components and behaviors have become decoupled from the customer
presentation and the provider has gained control of all VID/DMAC
endpoints.
One example of this is the 802.1ah work in hierarchical bridging
whereby customer Ethernet frames are fully encapsulated into a
provider Ethernet frame, isolating the customer VID/DMAC space from
the provider VID/DMAC space. Another example would be the direct
transport of pseudo wires PWs ["Dry Martini" or PW over layer 2]
where the Ethernet network fulfills the role of the PSN in the PWE
architecture [PWoPBT]. In both cases the behavior of the provider's
network is as per 802.1Q.
The Ethernet data plane provides protocol multiplexing via the ether
type field which allows encapsulation of different protocols
supporting various applications. More recently, the Carrier Ethernet
effort has created provider and customer separation that enables
another level of multiplexing. This in effect creates provider MAC
endpoints in the Ethernet sub-network controlled by the provider. In
this document we concentrate on the provider solutions and therefore
subsequent references to VLAN, VID and MAC refer to those under
provider control, be it in the backbone layer of 802.1ah or the PSN
Fedyk et.al Expires August 2007 Page 24
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
layer of "Dry Martini". Also in the case where the Customer service
is Ethernet, the Customer Ethernet service is the same native
Ethernet service with functions such as bridging, learning and
spanning trees all functioning over the provider infrastructure.
With the provider in exclusive control of their Ethernet sub-network
and all customer specific state pushed to the edges of that sub-
network, the ability of the provider to exploit latent Ethernet
behavior is facilitated. One key capability sought is to overcome
limitations, such as single spanning tree path for all traffic
within a VLAN, imposed by bridging (see [MYERS] for a discussion).
Bridging offers a simple solution for any-to-any connectivity within
a VLAN partition via the Spanning tree, flooding and MAC learning.
Spanning tree provides some unnecessary capabilities for point to
point services and since the Spanning tree must interconnect all
MACs with the same VLAN IDs (VIDs) it consumes a scarce resource
(VIDs). In this document we present that it is easier to modify
Ethernet to scale engineered P2P services and this is the approach
we take with PBB-TE and PW over Ethernet. (The number of usable
VLANs IDs in conventional Ethernet bridging is constrained to 4094,
therefore the use of VLAN only configuration for all forwarding
could be limited for some applications where large number of point
to point connections are required.) This is because in Ethernet,
each Spanning tree is associated with one or more VLAN IDs. Also
Port membership in a VLAN is configured which controls the
connectivity of all MAC interfaces participating in the VLAN.
The roots for PBB-TE capability exist in the Ethernet management
plane. The management of Ethernet switches provides for static
configuration of Ethernet forwarding. The Ethernet Control plane
allows for forwarding entries that are statically provisioned or
configured. In this document we are expanding the meaning of
"configured" from an Ethernet Control plane sense to mean either
provisioned, or controlled by GMPLS. The connectivity aspects of
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
each switch to determine the egress link (or links in the case of
link aggregation).
In this document, we discuss, point to point (P2P) and point to
multipoint (P2MP) connections via static configuration of VLAN/DMAC
tuples. (MAC-only configuration is considered a degenerate case
corresponding to VLAN zero).
This is a finer granularity than traditional VLAN networks since
each P2P connection is independent. By provisioning MAC addresses
independently of Spanning tree in a domain, both the VLAN and the
VLAN/DMAC configured forwarding can be exploited. This greatly
extends the scalability of what can be achieved in a pure Ethernet
bridged sub network.
Fedyk et al. Expires August 2007 Page 25
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
For compatibility and flexibility with existing Ethernet hardware,
we preserve the global/domain wide uniqueness and semantics of MAC
addresses as interface names or multicast group addresses. (In
Ethernet overlap of MAC addresses across VLANs is allowed. However
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
PBT-TE labels out of the global MAC address space or the local admin
space.) We then redefine the semantics associated with
administration and uses of VLAN values for the case of explicit
forwarding such as you get with statically configured Ethernet.
The result is a new architecture where configured VID + DMAC provide
a forwarding table that is consistent with existing Ethernet
switching. At the same time it provides domain wide labels that can
be controlled by a common GMPLS control plane. This makes GMPLS
control and resource management procedures ideal to create paths.
The outcome is that the GMPLS control plane can be utilized to set
up the following atomic modes of connectivity:
1) P2P connectivity and MP2P multiplexed connectivity based
on configuration of unicast MAC addresses in conjunction
with a VID from a set of pre-configured VIDs.
2) P2MP connectivity based on configuration of multicast MAC
address in conjunction with a VID from a set of pre-
configured VIDs. This corresponds to (Source, Group) or
(S,G) multicast.
3) P2MP connectivity based on configuration of VID port
membership. This corresponds to (S,*) or (*,*) multicast
(where * represents the extent of the VLAN Tree).
4) MP2MP connectivity based on configuration of VID port
membership (P2MP trees in which leaves are permitted to
communicate). Although, we caution that this approach
poses resilience issues (discussed in section 5) and hence
is not recommended.
The modes above are not completely distinct. Some modes involve
combinations of P2P connections in one direction and MP connectivity
in the other direction. Also, more than one mode may be combined in
a single GMPLS transaction. One example is the incremental addition
of a leaf to a P2MP tree with a corresponding MP2P return path
(analogous to a root initiated join).
In order to realize the above connectivity modes, a partition of the
VLAN IDs from traditional Ethernet needs to be established. The
partition allows for a pool of Ethernet labels for manual
configuration and/or for GMPLS control plane usage. The VID
partition actually consists of a "configured VID/DMAC range" and
"configured VID range" since in some instances the label is a
VID/DMAC and sometimes the label is a VID/Mulitcast DMAC.
A 2. Overview of configuration of VID/DMAC tuples
Fedyk et al. Expires August 2007 Page 26
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
Statically configured MAC and VID entries are a complete 60 bit
lookup The basic operation of an Ethernet switch is filtering on VID
and forwarding on DMAC. The resulting operation is the same as
performing a full 60 bit lookup (VID (12) + DMAC(48)) for point to
point operations, only requiring uniqueness of the full 60 bits for
forwarding to resolve correctly. We can call this an Ethernet domain
wide label.
We have complete route freedom for each domain wide label (60 bit
VLAN/DMAC tuple) and the ability to define multiple connectivity
instances or paths per DMAC for each of the VIDs in the "configured
VID/DMAC range".
We have preserved the semantics of MAC addresses, and simply broaden
the potential interpretations of VLAN ID from spanning tree
identifier to topology instance identifier. Therefore, we can
concurrently operate both standard bridging and configured
unicast/multicast operation side by side. We partition the VID space
and allocate a range of VIDs (say 'n' VIDs) as only significant when
combined with a configured DMAC address (the aforementioned
"configured VID/DMAC range" of VIDs). We can then consider a VID in
that range as an individual connectivity instance identifier for a
configured P2P path terminating at the associated DMAC address. Or
in the case of P2MP, a P2MP multicast tree corresponding to the
destination multicast group address. Note that this is destination
based forwarding consistent with how Ethernet works today. The only
thing changed is the mechanism of populating the forwarding tables.
Ethernet MAC addresses are typically globally unique since the 48
bits consists of 24 bit Organizational Unique Identifier and a 24
bit serial number. There is also a bit set aside for Multicast and
for local addresses out of the OUI field. We define domain wide as
within a single organization, or more strictly within a single
network within an organization. For provider MAC addresses that will
only be used in a domain wide sense we can define MAC addresses out
of a either the local space or the global space since they both have
the domain wide unique property. When used in the context of GMPLS,
it is useful to think of a domain wide pool of labels where switches
are assigned a set of MAC addresses. These labels are assigned
traffic that terminates on the respective switches.
It is also worth noting that unique identification of source in the
form of the SMAC is carried e2e in the MAC header. So although we
have a 60 bit domain wide unique label, it may be shared by multiple
sources and the full connection identifier for an individual P2P
instance is 108 bits (SMAC, VID and DMAC). The SMAC is not
referenced in forwarding operations but it would allow additional
context for tracing or other operations at the end of the path.
GMPLS signaling procedures can be designed to create the bi-
directional path delegating label allocation of the combined
VID/DMAC Label to the destination/source associated with the MACs
Fedyk et al. Expires August 2007 Page 27
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
for each direction of unicast forwarding. Creating P2P path is a
well understood control plane requirement.
For multicast group addresses, the VID/DMAC concatenated label can
be distributed by the source but label assignment (as it encodes
global multicast group information) requires coordination within the
GMPLS controlled domain.
As mentioned earlier, this technique results in a single unique and
invariant identifier, in our case a VID/DMAC label associated with
the path termination or the multicast group. There can be up to
4094 labels to any one MAC address. However, practically, from
Ethernet network wide aspect, there would be only a handful of VLANs
allocated for PBB-TE. In addition, all 48 bits are not completely
available for the MAC addresses. One way to maximize the space is
to use the locally administered space. This is a large number for
P2P applications and even larger when shared or multiplexed
forwarding is leveraged. In practice, most network scaling
requirements may be met via allocation of only a small portion of
the VID space, to the configured VID/DMAC range. The result is
minimal impact on the number of remaining bridging VLANs that can be
concurrently supported.
In order to use this unique 60 bit label, we disable the normal
mechanisms by which Ethernet populates the forwarding table for the
allocated range of VIDs. When a path is setup, for a specific label
across a contiguous sequence of Ethernet switches, a unidirectional
connection is the functional building block for an Ethernet Label
Switched path (Eth-LSP).
In P2P mode a bi-directional path is composed of two unidirectional
paths that are created with a single RSVP-TE session. The technique
does not require the VID to be common in both directions. However,
keeping in line with regular Ethernet these paths are symmetrical
such that a single bi-directional connection is composed of two
unidirectional paths that have common routing (i.e. traverse the
same switches and links) in the network and hence share the same
fate.
In P2MP mode a bi-directional path is composed of a unidirectional
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 common
routing as in the P2P case.
There are a few modifications required to standard Ethernet to make
this approach robust:
1. In Standard Ethernet, discontinuities in forwarding table
configuration in the path of a connection will normally result in
packets being flooded as "unknown". For configured operation (e.g.
PBB-TE), unknown addresses are indicative of a fault or
configuration error and the flooding of these is undesirable in
meshed topologies. Therefore flooding of "unknown" unicast/multicast
MAC addresses must be disabled for the "configured VID/DMAC range".
Fedyk et al. Expires August 2007 Page 28
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
2. MAC learning is not required, and although it will not interfere
with management/control population of the forwarding tables, since
static entries are not overridden, it appears prudent to explicitly
disable MAC learning for the configured VID/DMAC and VID range.
3. Spanning tree is disabled for the allocated VID/DMAC and VID
range and port blocking must be disabled to achieve complete
configured route freedom. As noted earlier, it is a control plane
requirement to ensure configured paths are loop free.
All three modifications described above are within the scope of
acceptable configuration options defined in IEEE802.1Q
specification.
A 3. Overview of configuration of VID port membership
Procedures almost identical to that for configuration of P2P
VID/DMAC tuples can also be used for the incremental configuration
of P2MP VID trees. For the replication of forwarding in this case
the label is common for the multipoint destinations. The MAC field
is set to multicast address and is common to the multicast
community. The VID is a distinguisher common to the multicast
community. The signaling procedures are as per that for [MPLS-P2MP].
Since VID translation is relatively new and is not a ubiquitously
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
assigned by management and nominally is required to be invariant
across the network. The ability to indicate permissibility of
translation will be addressed in a future version of the document.
A procedure known as "asymmetrical VID" may be employed to constrain
connectivity (root to leaves, and leaves to root only) when switches
also support shared VLAN learning (or SVL). This would be consistent
with the root as a point of failure.
A 4. OAM Aspects
Robustness is enhanced with the addition of data plane OAM to
provide both fault and performance management.
For the configured VID/DMAC unicast mode of behavior, the hardware
performs unicast packet forwarding of known MAC addresses exactly as
Ethernet currently operates. The OAM currently defined,[802.1ag and
Y.1731] can also be reused without 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 plane
forwarding, is the tight coupling of the 60 bit unique connection ID
(VID/DMAC) and the associated OAM packets. It is a simple matter to
Fedyk et al. Expires August 2007 Page 29
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
determine a broken path or misdirected packet since the unique
connection ID cannot be altered on the Eth-LSP. This is in fact one
of the most powerful and unique aspects of the domain wide label for
any type of rapid diagnosis of the data plane faults. It is also
independent of the control plane so it works equally well for
provisioned or GMPLS controlled paths.
Bi-directional transactions (e.g. ETH-LB) and reverse direction
transactions (e.g. ETH-AIS) MAY have a different VID for each
direction. Currently Y.1731 & 802.1ag makes no representations with
respect to this.
For configured multicast VID/DMAC mode, the current versions of
802.1ag and Y.1731] make no representation as to how PDUs which are
not using unicast addresses or which use OAM reserved multicast
addresses are handled. Therefore this specification makes no
representation as to whether such trees can be instrumented.
When configured VID mode of operation is used PBB-TE can be forced
to use the same VID in both directions, emulating the current
Ethernet data plane and the OAM functions as defined in the current
versions of 802.1ag and Y.1731 can be used with no restriction.
A 5. QOS Aspects
Ethernet VLAN tags include priority tagging in the form of the
802.1p priority bits. When combined with configuration of the paths
via management or control plane, priority tagging produces the
Ethernet equivalent of an MPLS-TE E-LSPs [RFC3270]. Priority tagged
Ethernet PDUs self-identify the required queuing discipline
independent of the configured connectivity.
It should be noted that the consequence of this is that there is a
common COS model across the different modes of configured operation
specified in this document.
The actual QOS objects required for signaling will be in a future
version of this memo.
A 6. Resiliency Aspects
A 6.1 E2E Path protection
One for One(1:1) protection is a primary LSP with a disjoint
dedicated back up LSP. One plus one (1+1) protection is a primary
LSP with a disjoint backup LSP that may share resources with other
LSPs. One for One and One plus One Automatic Protection Switching
strategies are supported. Such schemes offer:
1) Engineered disjoint protection paths that can protect both
directions of traffic.
2) Fast switchover due to tunable OAM mechanisms.
3) Revertive path capability when primary paths are restored.
4) Option for redialing paths under failure.
Fedyk et al. Expires August 2007 Page 30
Internet Draft draft-fedyk-gmpls-ethernet-pbt-te-00.txt
Specific procedures for establishment of protection paths and
associating paths into "protection groups" are TBD.
Note that E2E path protection is able to respond to failures with a
number of configurable intervals. The loss of CCM OAM cells or ETH-
AIS cells in the data plane can trigger paths to switch. In the case
of CCM OAM cells, the detection time is typically 3.5 times the CCM
interval plus the propagation delay from the fault.
Fedyk et al. Expires August 2007 Page 31
| PAFTECH AB 2003-2026 | 2026-04-23 01:37:19 |