Request for Comments: 4202 Y. Rekhter, Ed.
Category: Standards Track Juniper Networks
October 2005
Routing Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies routing extensions in support of carrying
link state information for Generalized Multi-Protocol Label Switching
(GMPLS). This document enhances the routing extensions required to
support MPLS Traffic Engineering (TE).
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements for Layer-Specific TE Attributes . . . . . 4
1.2. Excluding Data Traffic from Control Channels. . . . . . 6
2. GMPLS Routing Enhancements. . . . . . . . . . . . . . . . . . 7
2.1. Support for Unnumbered Links. . . . . . . . . . . . . . 7
2.2. Link Protection Type. . . . . . . . . . . . . . . . . . 7
2.3. Shared Risk Link Group Information. . . . . . . . . . . 9
2.4. Interface Switching Capability Descriptor . . . . . . . 9
2.4.1. Layer-2 Switch Capable. . . . . . . . . . . . . 11
2.4.2. Packet-Switch Capable . . . . . . . . . . . . . 11
2.4.3. Time-Division Multiplex Capable . . . . . . . . 12
2.4.4. Lambda-Switch Capable . . . . . . . . . . . . . 13
2.4.5. Fiber-Switch Capable. . . . . . . . . . . . . . 13
2.4.6. Multiple Switching Capabilities per Interface . 13
2.4.7. Interface Switching Capabilities and Labels . . 14
2.4.8. Other Issues. . . . . . . . . . . . . . . . . . 14
2.5. Bandwidth Encoding. . . . . . . . . . . . . . . . . . . 15
3. Examples of Interface Switching Capability Descriptor . . . . 15
3.1. STM-16 POS Interface on a LSR . . . . . . . . . . . . . 15
3.2. GigE Packet Interface on a LSR. . . . . . . . . . . . . 15
3.3. STM-64 SDH Interface on a Digital Cross Connect with
Standard SDH. . . . . . . . . . . . . . . . . . . . . . 15
3.4. STM-64 SDH Interface on a Digital Cross Connect with
Two Types of SDH Multiplexing Hierarchy Supported . . . 16
3.5. Interface on an Opaque OXC (SDH Framed) with Support
for One Lambda per Port/Interface . . . . . . . . . . . 16
3.6. Interface on a Transparent OXC (PXC) with External
DWDM that understands SDH framing . . . . . . . . . . . 17
3.7. Interface on a Transparent OXC (PXC) with External
DWDM That Is Transparent to Bit-Rate and Framing. . . . 17
3.8. Interface on a PXC with No External DWDM. . . . . . . . 18
3.9. Interface on a OXC with Internal DWDM That Understands
SDH Framing . . . . . . . . . . . . . . . . . . . . . . 18
3.10. Interface on a OXC with Internal DWDM That Is
Transparent to Bit-Rate and Framing . . . . . . . . . . 19
4. Example of Interfaces That Support Multiple Switching
Capabilities. . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Interface on a PXC+TDM Device with External DWDM. . . . 20
4.2. Interface on an Opaque OXC+TDM Device with External
DWDM. . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Interface on a PXC+LSR Device with External DWDM. . . . 21
4.4. Interface on a TDM+LSR Device . . . . . . . . . . . . . 21
5. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References. . . . . . . . . . . . . . . . . . 23
7.2. Informative References. . . . . . . . . . . . . . . . . 24
8. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
This document specifies routing extensions in support of carrying
link state information for Generalized Multi-Protocol Label Switching
(GMPLS). This document enhances the routing extensions [ISIS-TE],
[OSPF-TE] required to support MPLS Traffic Engineering (TE).
Traditionally, a TE link is advertised as an adjunct to a "regular"
link, i.e., a routing adjacency is brought up on the link, and when
the link is up, both the properties of the link are used for Shortest
Path First (SPF) computations (basically, the SPF metric) and the TE
properties of the link are then advertised.
GMPLS challenges this notion in three ways. First, links that are
not capable of sending and receiving on a packet-by-packet basis may
yet have TE properties; however, a routing adjacency cannot be
brought up on such links. Second, a Label Switched Path can be
advertised as a point-to-point TE link (see [LSP-HIER]); thus, an
advertised TE link may be between a pair of nodes that don’t have a
routing adjacency with each other. Finally, a number of links may be
advertised as a single TE link (perhaps for improved scalability), so
again, there is no longer a one-to-one association of a regular
routing adjacency and a TE link.
Thus we have a more general notion of a TE link. A TE link is a
"logical" link that has TE properties. The link is logical in a
sense that it represents a way to group/map the information about
certain physical resources (and their properties) into the
information that is used by Constrained SPF for the purpose of path
computation, and by GMPLS signaling. This grouping/mapping must be
done consistently at both ends of the link. LMP [LMP] could be used
to check/verify this consistency.
Depending on the nature of resources that form a particular TE link,
for the purpose of GMPLS signaling, in some cases the combination of
<TE link identifier, label> is sufficient to unambiguously identify
the appropriate resource used by an LSP. In other cases, the
combination of <TE link identifier, label> is not sufficient; such
cases are handled by using the link bundling construct [LINK-BUNDLE]
that allows to identify the resource by <TE link identifier,
Component link identifier, label>.
Some of the properties of a TE link may be configured on the
advertising Label Switching Router (LSR), others which may be
obtained from other LSRs by means of some protocol, and yet others
which may be deduced from the component(s) of the TE link.
A TE link between a pair of LSRs doesn’t imply the existence of a
routing adjacency (e.g., an IGP adjacency) between these LSRs. As we
mentioned above, in certain cases a TE link between a pair of LSRs
could be advertised even if there is no routing adjacency at all
between the LSRs (e.g., when the TE link is a Forwarding Adjacency
(see [LSP-HIER])).
A TE link must have some means by which the advertising LSR can know
of its liveness (this means may be routing hellos, but is not limited
to routing hellos). When an LSR knows that a TE link is up, and can
determine the TE link’s TE properties, the LSR may then advertise
that link to its (regular) neighbors.
In this document, we call the interfaces over which regular routing
adjacencies are established "control channels".
[ISIS-TE] and [OSPF-TE] define the canonical TE properties, and say
how to associate TE properties to regular (packet-switched) links.
This document extends the set of TE properties, and also says how to
associate TE properties with non-packet-switched links such as links
between Optical Cross-Connects (OXCs). [LSP-HIER] says how to
associate TE properties with links formed by Label Switched Paths.
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 BCP 14, RFC 2119
[RFC2119].
1.1. Requirements for Layer-Specific TE Attributes
In generalizing TE links to include traditional transport facilities,
there are additional factors that influence what information is
needed about the TE link. These arise from existing transport layer
architecture (e.g., ITU-T Recommendations G.805 and G.806) and
associated layer services. Some of these factors are:
1. The need for LSPs at a specific adaptation, not just a particular
bandwidth. Clients of optical networks obtain connection services
for specific adaptations, for example, a VC-3 circuit. This not
only implies a particular bandwidth, but how the payload is
structured. Thus the VC-3 client would not be satisfied with any
LSP that offered other than 48.384 Mbit/s and with the expected
structure. The corollary is that path computation should be able
to find a route that would give a connection at a specific
adaptation.
2. Distinguishing variable adaptation. A resource between two OXCs
(specifically a G.805 trail) can sometimes support different
adaptations at the same time. An example of this is described in
section 2.4.8. In this situation, the fact that two adaptations
are supported on the same trail is important because the two
layers are dependent, and it is important to be able to reflect
this layer relationship in routing, especially in view of the
relative lack of flexibility of transport layers compared to
packet layers.
3. Inheritable attributes. When a whole multiplexing hierarchy is
supported by a TE link, a lower layer attribute may be applicable
to the upper layers. Protection attributes are a good example of
this. If an OC-192 link is 1+1 protected (a duplicate OC-192
exists for protection), then an STS-3c within that OC-192 (a
higher layer) would inherit the same protection property.
4. Extensibility of layers. In addition to the existing defined
transport layers, new layers and adaptation relationships could
come into existence in the future.
5. Heterogeneous networks whose OXCs do not all support the same set
of layers. In a GMPLS network, not all transport layer network
elements are expected to support the same layers. For example,
there may be switches capable of only VC-11, VC-12, and VC-3, and
there may be others that can only support VC-3 and VC-4. Even
though a network element cannot support a specific layer, it
should be able to know if a network element elsewhere in the
network can support an adaptation that would enable that
unsupported layer to be used. For example, a VC-11 switch could
use a VC-3 capable switch if it knew that a VC-11 path could be
constructed over a VC-3 link connection.
From the factors presented above, development of layer specific GMPLS
routing documents should use the following principles for TE-link
attributes.
1. Separation of attributes. The attributes in a given layer are
separated from attributes in another layer.
2. Support of inter-layer attributes (e.g., adaptation
relationships). Between a client and server layer, a general
mechanism for describing the layer relationship exists. For
example, "4 client links of type X can be supported by this server
layer link". Another example is being able to identify when two
layers share a common server layer.
3. Support for inheritable attributes. Attributes which can be
inherited should be identified.
4. Layer extensibility. Attributes should be represented in routing
such that future layers can be accommodated. This is much like
the notion of the generalized label.
5. Explicit attribute scope. For example, it should be clear whether
a given attribute applies to a set of links at the same layer.
The present document captures general attributes that apply to a
single layer network, but doesn’t capture inter-layer relationships
of attributes. This work is left to a future document.
1.2. Excluding Data Traffic from Control Channels
The control channels between nodes in a GMPLS network, such as OXCs,
SDH cross-connects and/or routers, are generally meant for control
and administrative traffic. These control channels are advertised
into routing as normal links as mentioned in the previous section;
this allows the routing of (for example) RSVP messages and telnet
sessions. However, if routers on the edge of the optical domain
attempt to forward data traffic over these channels, the channel
capacity will quickly be exhausted.
In order to keep these control channels from being advertised into
the user data plane a variety of techniques can be used.
If one assumes that data traffic is sent to BGP destinations, and
control traffic to IGP destinations, then one can exclude data
traffic from the control plane by restricting BGP nexthop resolution.
(It is assumed that OXCs are not BGP speakers.) Suppose that a
router R is attempting to install a route to a BGP destination D. R
looks up the BGP nexthop for D in its IGP’s routing table. Say R
finds that the path to the nexthop is over interface I. R then
checks if it has an entry in its Link State database associated with
the interface I. If it does, and the link is not packet-switch
capable (see [LSP-HIER]), R installs a discard route for destination
D. Otherwise, R installs (as usual) a route for destination D with
nexthop I. Note that R need only do this check if it has packet-
switch incapable links; if all of its links are packet-switch
capable, then clearly this check is redundant.
In other instances it may be desirable to keep the whole address
space of a GMPLS routing plane disjoint from the endpoint addresses
in another portion of the GMPLS network. For example, the addresses
of a carrier network where the carrier uses GMPLS but does not wish
to expose the internals of the addressing or topology. In such a
network the control channels are never advertised into the end data
network. In this instance, independent mechanisms are used to
advertise the data addresses over the carrier network.
Other techniques for excluding data traffic from control channels may
also be needed.
2. GMPLS Routing Enhancements
In this section we define the enhancements to the TE properties of
GMPLS TE links. Encoding of this information in IS-IS is specified
in [GMPLS-ISIS]. Encoding of this information in OSPF is specified
in [GMPLS-OSPF].
2.1. Support for Unnumbered Links
An unnumbered link has to be a point-to-point link. An LSR at each
end of an unnumbered link assigns an identifier to that link. This
identifier is a non-zero 32-bit number that is unique within the
scope of the LSR that assigns it.
Consider an (unnumbered) link between LSRs A and B. LSR A chooses an
idenfitier for that link. So does LSR B. From A’s perspective we
refer to the identifier that A assigned to the link as the "link
local identifier" (or just "local identifier"), and to the identifier
that B assigned to the link as the "link remote identifier" (or just
"remote identifier"). Likewise, from B’s perspective the identifier
that B assigned to the link is the local identifier, and the
identifier that A assigned to the link is the remote identifier.
Support for unnumbered links in routing includes carrying information
about the identifiers of that link. Specifically, when an LSR
advertises an unnumbered TE link, the advertisement carries both the
local and the remote identifiers of the link. If the LSR doesn’t
know the remote identifier of that link, the LSR should use a value
of 0 as the remote identifier.
2.2. Link Protection Type
The Link Protection Type represents the protection capability that
exists for a link. It is desirable to carry this information so that
it may be used by the path computation algorithm to set up LSPs with
appropriate protection characteristics. This information is
organized in a hierarchy where typically the minimum acceptable
protection is specified at path instantiation and a path selection
technique is used to find a path that satisfies at least the minimum
acceptable protection. Protection schemes are presented in order
from lowest to highest protection.
This document defines the following protection capabilities:
Extra Traffic
If the link is of type Extra Traffic, it means that the link is
protecting another link or links. The LSPs on a link of this type
will be lost if any of the links it is protecting fail.
Unprotected
If the link is of type Unprotected, it means that there is no
other link protecting this link. The LSPs on a link of this type
will be lost if the link fails.
Shared
If the link is of type Shared, it means that there are one or more
disjoint links of type Extra Traffic that are protecting this
link. These Extra Traffic links are shared between one or more
links of type Shared.
Dedicated 1:1
If the link is of type Dedicated 1:1, it means that there is one
dedicated disjoint link of type Extra Traffic that is protecting
this link.
Dedicated 1+1
If the link is of type Dedicated 1+1, it means that a dedicated
disjoint link is protecting this link. However, the protecting
link is not advertised in the link state database and is therefore
not available for the routing of LSPs.
Enhanced
If the link is of type Enhanced, it means that a protection scheme
that is more reliable than Dedicated 1+1, e.g., 4 fiber
BLSR/MS-SPRING, is being used to protect this link.
The Link Protection Type is optional, and if a Link State
Advertisement doesn’t carry this information, then the Link
Protection Type is unknown.
2.3. Shared Risk Link Group Information
A set of links may constitute a ’shared risk link group’ (SRLG) if
they share a resource whose failure may affect all links in the set.
For example, two fibers in the same conduit would be in the same
SRLG. A link may belong to multiple SRLGs. Thus the SRLG
Information describes a list of SRLGs that the link belongs to. An
SRLG is identified by a 32 bit number that is unique within an IGP
domain. The SRLG Information is an unordered list of SRLGs that the
link belongs to.
The SRLG of a LSP is the union of the SRLGs of the links in the LSP.
The SRLG of a bundled link is the union of the SRLGs of all the
component links.
If an LSR is required to have multiple diversely routed LSPs to
another LSR, the path computation should attempt to route the paths
so that they do not have any links in common, and such that the path
SRLGs are disjoint.
The SRLG Information may start with a configured value, in which case
it does not change over time, unless reconfigured.
The SRLG Information is optional and if a Link State Advertisement
doesn’t carry the SRLG Information, then it means that SRLG of that
link is unknown.
2.4. Interface Switching Capability Descriptor
In the context of this document we say that a link is connected to a
node by an interface. In the context of GMPLS interfaces may have
different switching capabilities. For example an interface that
connects a given link to a node may not be able to switch individual
packets, but it may be able to switch channels within an SDH payload.
Interfaces at each end of a link need not have the same switching
capabilities. Interfaces on the same node need not have the same
switching capabilities.
The Interface Switching Capability Descriptor describes switching
capability of an interface. For bi-directional links, the switching
capabilities of an interface are defined to be the same in either
direction. I.e., for data entering the node through that interface
and for data leaving the node through that interface.
A Link State Advertisement of a link carries the Interface Switching
Capability Descriptor(s) only of the near end (the end incumbent on
the LSR originating the advertisement).
An LSR performing path computation uses the Link State Database to
determine whether a link is unidirectional or bidirectional.
For a bidirectional link the LSR uses its Link State Database to
determine the Interface Switching Capability Descriptor(s) of the
far-end of the link, as bidirectional links with different Interface
Switching Capabilities at its two ends are allowed.
For a unidirectional link it is assumed that the Interface Switching
Capability Descriptor at the far-end of the link is the same as at
the near-end. Thus, an unidirectional link is required to have the
same interface switching capabilities at both ends. This seems a
reasonable assumption given that unidirectional links arise only with
packet forwarding adjacencies and for these both ends belong to the
same level of the PSC hierarchy.
This document defines the following Interface Switching Capabilities:
Packet-Switch Capable-1 (PSC-1)
Packet-Switch Capable-2 (PSC-2)
Packet-Switch Capable-3 (PSC-3)
Packet-Switch Capable-4 (PSC-4)
Layer-2 Switch Capable (L2SC)
Time-Division-Multiplex Capable (TDM)
Lambda-Switch Capable (LSC)
Fiber-Switch Capable (FSC)
If there is no Interface Switching Capability Descriptor for an
interface, the interface is assumed to be packet-switch capable
(PSC-1).
Interface Switching Capability Descriptors present a new constraint
for LSP path computation.
Irrespective of a particular Interface Switching Capability, the
Interface Switching Capability Descriptor always includes information
about the encoding supported by an interface. The defined encodings