[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00
Network Working Group Kireeti Kompella (Juniper Networks)
Internet Draft Yakov Rekhter (cisco Systems)
Expiration Date: August 2000 Daniel O. Awduche (UUNET)
Alan Hannan (Global Crossing)
Gisli Hjalmtysson (AT&T Labs)
Joe Lawrence (Level 3 Communications)
Satoru Okamoto (NTT)
Debashis Basak (Marconi)
Greg Bernstein (Ciena Corporation)
John Drake (Chromisys)
Near Margalit (New Access Communications)
Ed Stern (Sirocco Systems)
Extensions to IS-IS/OSPF and RSVP in support of MPL(ambda)S
draft-kompella-mpls-optical-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Kompella/Rekhter et al
[Page 1]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
2. Abstract
This document specifies extensions to the IS-IS, OSPF, and RSVP in
support of Multiprotocol Lambda Switching (MPL(ambda)S). For
motivations and the overall architecture of MPL(amda)S see [Awduche-
1]. For the set of required enhancements to IS-IS, OSPF, and RSVP
see [Basak].
3. IS-IS/OSPF enhancements
In this section we describe enhancements to IS-IS and OSPF in support
of MPL(ambda)S. These enhancements are in addition to the extensions
required to support MPLS Traffic Engineering [Smit], [Katz].
3.1. Link Type TLV
A network may have links with different characteristics. For example,
a node may not be able to demultiplex the data it receives on a given
link on a packet-by-packet basis, but it may be to multiplex or
demultiplex channels within a SONET payload.
The Link Type sub-TLV allows to identify a particular type of a link.
In IS-IS, this TLV is a sub-TLV of the Extended IS Reachability TLV,
with type 19. In OSPF, this TLV is a sub-TLV of the Link TLV, with
type 1 (this sub-TLV currently exists in OSPF; here, we extend the
range of values, and introduce a further sub-TLV.)
The length is 1 plus the total length of all sub-TLVs. The value has
a fixed length field of one octet, followed by optional sub-TLVs.
The value is taken from the following list:
Value Link Type
1 Packet-Switch Capable-1 (PSC-1)
2 Packet-Switch Capable-2 (PSC-2)
3 Packet-Switch Capable-3 (PSC-3)
4 Packet-Switch Capable-4 (PSC-4)
200 Time-Division-Multiplex Capable (TDM)
210 Lambda-Switch Capable (LSC)
220 Fiber-Switch Capable (FSC)
240 Forwarding Adjacency PSC (FA-PSC)
245 Forwarding Adjacency TDM (FA-TDM)
250 Forwarding Adjacency LSC (FA-LSC)
If a link is of type PSC-1 through PSC-4, that means that the node
receiving data over this link can demultiplex (switch) the received
Kompella/Rekhter et al
[Page 2]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
data on a packet-by-packet basis. The various levels of PSC
establish a hierarchy of LSPs tunneled within LSPs.
If a link is of type TDM, that means that the node receiving data
over this link can multiplex or demultiplex channels within a SONET
payload.
If a link is of type LSC, that means that the node receiving data
over this link can recognise and switch individual lambdas within the
link (fiber).
If a link is of type FSC, that means that the node receiving data
over this link (fiber) can switch the entire contents to another link
(fiber) (without distinguishing lambdas, channels or packets).
If a link is of type FA-PSC, that means that the link is a forwarding
adjacency (see section 3.5). Furthermore, the egress node of the
corresponding FA-LSP is capable of switching the data received over
the FA-LSP on a packet-by-packet basis.
If a link is of type FA-TDM, that means that the link is a forwarding
adjacency. Furthermore, the egress node of the corresponding FA-LSP
is capable of multiplexing and demultiplexing the SONET channels
received over the FA-LSP.
If a link is of type FA-LSC, that means that the link is a forwarding
adjacency. Furthermore, the egress node of the corresponding FA-LSP
is capable of recognising and switching the lambdas received over the
FA-LSP.
3.2. Link Media Type TLV
A link may support a set of media types, where by media type we mean
both the bit encoding format as well as the bit transmission rate.
By support we mean that the link has the ability to carry and switch
a signal of one or more of these media types depending on the
resource availability and capacity of the link. The link media type
should not be confused with the physical link encoding or multiplex
structure (if any). These properties are of local significance
between neighbor nodes. The types of media a link can support (and
its associated node switch) are of overall concern to routing as well
as information on link capacity (bandwidth).
A typical example of multiple transport methods with the same routing
representation currently occurs in the optical domain. Currently
there are systems where four OC-48s are switched and transported
over a single fiber via wavelength division multiplexing (WDM)
Kompella/Rekhter et al
[Page 3]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
technology. In addition there are systems where four OC-48s are
transported in a "transparent" OC-192 time division multiplex (TDM)
structure, i.e., all the overheads of the OC-48's are persevered. In
both these cases the essential information from a routing perspective
is that the links can both transport media of type OC-48.
The Link Media Type TLV is a list of supported media types for a
link. In IS-IS, this TLV is a sub-TLV of the Extended IS
Reachability TLV with type 20. In OSPF, this TLV is a sub-TLV of the
Link TLV, with type 10.
The length is the length of the list of Link Media Types in octets.
The value is a list of two-tuples of which the first field is a two-
octet value which defines the media type, and the second field is a
one-octet value which defines the lowest priority at which that media
type is available. Media types values are taken from the following
list:
Value Bit Rate Encoding
<n> OC-<n> SONET 1 <= <n> <= 3072
3072 + <n> OC-<n> SDH 1 <= <n> <= 3072
6144 + <n> OC-<n> Clear 1 <= <n> <= 3072
9217 DS0 DS0
9218 DS1 DS1
9219 E1 E1
9220 DS2 DS2
9221 E2 E2
9222 DS3 DS3
9223 E3 E3
9224 J3 J3
9225 DS4 DS4
9226 E4 E4
9227 J4 J4
9228 1Gbps GigE
9229 10Gbps 10GigE
Link Media Types (LMTs) present a new constraint for LSP path
computation. Specifically, when a sequence of links traversed by an
LSP includes one or more subsequence of links that carry the LMT TLV,
then for all the links within each such subsequence their bit rate
(as specified in the LMT TLV) has to be the same and at least the
LSP's desired bandwidth, and the encoding (as specified in the LMT
TLV) has to be the same.
On a bundled link we assume that either the whole link is configured
with the Link Media Types, or each of its component links are
configured with the Link Media Types. In the latter case, the Link
Kompella/Rekhter et al
[Page 4]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
Media Type of the bundled link is set to the set union of the Link
Media Types for all the component links.
3.2.1. Path sub-TLV
When an LSP advertises a forwarding adjacency into an IGP (IS-IS or
OSPF), it may be desirable to carry the information about the path
taken by this adjacency. This information may be used for path
calculation by other LSRs. This information is carried in the Path
sub-TLV, which is a sub-TLV of the Link Type TLV.
In both IS-IS and OSPF, this sub-TLV is encoded as follows: the type
is 1, the length is 4 times the path length, and the value is a list
of 4 octet IPv4 addresses identifying the links in the order that
they form the path of the forwarding adjacency.
3.2.2. Identifying links that can't terminate an LSP
As discussed in [Basak], some links may not be capable of terminating
LSPs, and this property of the links needs to be taken into account
when performing LSP path computation as well as RSVP signalling. Such
links are identified by using the Link Type sub-TLV.
Note that the notion of 'Termination Capable' has been generalized to
'packet-switch capable', 'TDM capable', 'lambda-switch capable', and
'fiber-switch capable'.
3.3. Shared Risk Link Group TLV
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 TLV
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 of a path is the union of the SRLGs of the links in the
path. If an LSP is required to have multiple diversely routed paths,
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.
In IS-IS, the SRLG TLV is a sub-TLV of the Extended IS Reachability
TLV with type 21. In OSPF, this TLV is a sub-TLV of the Link TLV,
with type 11. The length is the length of the list in octets. The
Kompella/Rekhter et al
[Page 5]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
value is an unordered list of 32 bit numbers that are the SRLGs that
the link belongs to.
3.4. Control channels, data channels, and IP links
A pair of OXCs are neighbors from the MPLS point of view if they are
connected by both one or more fibers and one or more (logical)
control channels. In what follows, we consider only those fibers
that it is desired to announce into IS-IS/OSPF for LSP establishment.
(The administrator may decide to reserve some fibers, for example for
manual provisioning; these fibers are not to be announced into IS-
IS/OSPF.)
For a given pair of OXCs connected by a set of fibers and one or more
(logical) control channels, both of the OXCs must associate the
fibers in the set with the control channels and form IP links in a
consistent fashion. One way to accomplish this is via configuration.
While other mechanisms to accomplish this may be possible, the
specification of such mechanisms is outside the scope of this
document.
If all the fibers can share the same TE characteristics, then a
single control channel suffices. From the IS-IS/OSPF point of view
this control channel, together with all the fibers, forms a single IP
link. This IP link could be either unnumbered, or numbered.
There are cases where all the fibers between a pair of OXCs cannot be
announced as one IS-IS/OSPF link. This may be because not all the
fibers can share the same TE characteristics (for example, some are
Termination Capable and others are not). Or this may be because it is
administratively so desired, for example, some fibers have metric 10
and others metric 20. In such a case, the fibers must be divided into
sets that share all TE characteristics, Corresponding to each set,
there must be a logical control channel. Each set of fibers, together
with the corresponding logical control channel forms an IP link. Each
such link should be numbered. All the multiple logical control
channels could be realized via the common control channel.
When an adjacency is established over a (logical) control channel
that is part of an IP link formed by the channel and a set of fibers,
this link is announced into IS-IS/OSPF as a "normal" link; the fiber
characteristics are represented as TE parameters of that link. If
there are more than one fiber in the set, the set is announced using
the "bundling" technique described in [Kompella].
Note that while there may be as many adjacencies established as there
are logical control channels, for flooding purposes, it suffices to
Kompella/Rekhter et al
[Page 6]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
flood over a single logical control channel.
3.4.1. Excluding data traffic from control channels
The control channels between OXCs, or between an OXC and a router are
generally meant for low-bandwidth control and administrative traffic.
These control channels are advertised into IS-IS/OSPF as normal IP
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.
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, 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.
Other techniques for excluding data traffic from control channels may
also be needed.
3.5. Forwarding adjacencies
An LSR at the head end of an LSP may advertise this LSP as a link
into a link-state IGP (e.g., IS-IS, OSPF). When this link is
advertised into the same instance of the IGP as the one that
determines the route taken by the LSP, we call such a link a
"forwarding adjacency". We refer to the LSP as the "forwarding
adjacency LSP", or just FA-LSP.
In general, creation/termination of a forwarding adjacency and its
FA-LSP could be driven either by mechanisms outside of MPLS (e.g.,
via configuration control on the LSR at the head-end of the
adjacency), or by mechanisms within MPLS (e.g., as a result of the
LSR at the head-end of the adjacency receiving LSP setup requests
originated by some other LSRs).
Kompella/Rekhter et al
[Page 7]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
Forwarding adjacencies are by definition unidirectional.
Forwarding adjacencies could be represented as unnumbered links. In
this case the link IP addresses of forwarding adjacencies are the
router IDs on the two ends of the link. Alternatively, forwarding
adjacencies could be represented as numbered links. In this case the
link IP addresses of forwarding adjacencies could be addresses
assigned to some "virtual" interfaces on a router (it is assumed that
a router may have multiple virtual interfaces).
If there are multiple LSPs that all originate on one LSR, and all
terminate on another LSR, then at one end of the spectrum all these
LSPs could be merged (under control of the head-end LSR) into a
single forwarding adjacency, while at the other end of the spectrum
each such LSP could be advertised as its own adjacency.
When a forwarding adjacency is created under administrative control
(static provisioning), the following parameters can be configured for
the FA-LSP: the head-end address (if left blank, this will default to
the head-end LSR's Router ID); the tail-end address (this must be
configured, and must be either the Router ID of the tail-end LSR of
the forwarding adjacency, or an interface address on the tail-end
LSR); bandwidth and resource colors constraints. The path taken by
the FA-LSP may be computed by the Constrained SPF (CSPF) mechanism of
MPLS TE, or by explicit configuration; this choice is determined by
configuration.
When a forwarding adjacency is created dynamically, its parameters
are inherited from the LSP which induced its creation. Note that the
bandwidth of the FA-LSP must be at least as big as the LSP that
induced it, but may be bigger if only discrete bandwidths are
available for the FA-LSP.
When the FA-LSP is established, it is advertised as a forwarding
adjacency into IS-IS/OSPF. The Link Type associated with the
forwarding adjacency depends on the link type of the last link in the
FA-LSP; if this link is packet-switch capable, the Link Type of the
forwarding adjacency is 'FA-PSC'; if this link is TDM capable, the
Link Type is 'FA-TDM'; if this link is lambda-switch capable, the
Link Type is 'FA-LSC'. Some of the attributes of this link can be
derived from those of the FA-LSP, but others will need to be
configured. Configuration of the attributes of statically
provisioned forwarding adjacencies is straightforward; for
dynamically provisioned forwarding adjacencies, a policy-based
mechanism may be needed to associate attributes to forwarding
adjacencies. The path taken by the forwarding adjacency may be
advertised using the Path sub-TLV.
Kompella/Rekhter et al
[Page 8]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
The Link Media Type of the forwarding adjacency is the most
restrictive of the link media types of the components links of the
forwarding adjacency. If none of the components links have a link
media type, the link associated with the forwarding adjacency doesn't
have a link media type either.
This document restricts the priority of the forwarding adjacency to
0, regardless of how the adjacency is created.
By default the maximum reservable bandwidth and the maximum LSP
bandwidth for all priorities of a link associated with a forwarding
adjacency is set to the bandwidth of the FA-LSP. These may be
overridden via configuration at the head-end of the forwarding
adjacency (note that the maximum LSP bandwidth at any priority should
be no more than the bandwidth of the FA-LSP).
By default the TE metric on the forwarding adjacency is set to max(1,
(the TE metric of the FA-LSP path) - 1) so that it attracts traffic
in preference to setting up a new LSP. This may be overridden via
configuration at the head-end of the forwarding adjacency.
It is expected that forwarding adjacencies will not be used for
establishing IGP peering relation between the routers at the ends of
the adjacency. It is further expected that forwarding adjacencies
will be used only in CSPF computation. In IS-IS, this can be
accomplished by setting the default metric of the extended IS
reachability TLV the link to infinity (2^24 - 1), and not advertising
an IS reachability TLV for the link. In OSPF, this can be
accomplished by not advertising the link as a regular LSA, but only
as a TE opaque LSA.
If forwarding adjacencies are to be established only under
administrative control, it is important that LSRs would not attempt
to establish LSPs that have to traverse the optical domain, but for
which no FA-LSP is established. To accomplish this, all the optical
links (fibers) within the optical domain have to be excluded from
CSPF by any LSR outside the domain. This can be achieved by coloring
optical links with a specific color, and making sure that all LSPs
originating outside the optical domain exclude this color.
3.6. Two-way connectivity check suppression
CSPF should not perform two-way connectivity check on the links used
by CSPF. This is because some of these links may be associated with
forwarding adjacencies, and therefore are unidirectional.
Kompella/Rekhter et al
[Page 9]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
4. RSVP changes
In this section we describe enhancements to RSVP in support of
MPL(ambda)S. These enhancements are in addition to the extensions
required to support MPLS Traffic Engineering [Awduche-2].
4.1. Label request object modification
The first field in the Label Request object is changed to contain the
Link Media Type. When an LSR receives a Path message, it must
allocate a label, lambda or channel that is compatible with the Link
Media Type. The values for Link Media type as the same as for the
two-octet media type values in IS-IS/OSPF Link Media Type TLV.
If the choice of label, lambda or channel is not to be restricted, a
Link Media Type of 0 is to be used.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Media Type | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2. Label object modification
The information carried in the Label Object should be sufficient to
control the connectivity matrix on an OXC, even when there are
multiple fibers between a pair of OXCs, and (at least some, or even
all of) these fibers can't be used for exchanging MPLS control
information between these two OXCs, and these fibers are combined
into bundled links.
That is, the Label Object should identify both a specific fiber
(e.g., as an Interface Index), and a specific wavelength within that
fiber, or a specific channel within that fiber. Which of the two is
intended should be obvious to the receiver of the Resv message. The
special value of 0xffff for the lambda or channel means the whole
fiber.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber (16 bits) | Lambda (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
Kompella/Rekhter et al
[Page 10]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fiber (16 bits) | Channel (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3. LSP aggregation via nesting
4.3.1. Domains
Define an ordering among link types as follows: PSC-1 < PSC-2 < PSC-3
< PSC-4 < TDM < LSC < FSC. Say that a link type x is compatible with
link type y iff x equals y, or x and y are both packet-switch
capable.
Suppose an LSP's path is as follows: node-0, link-1, node-1, link-2,
node-2, ..., link-n, node-n; let the link type of link-i be lt-i. If
lt-i < lt-(i+1), we say that the LSP has crossed a domain boundary at
node-i; with respect to that LSP path, the LSR at node-i is an edge
LSR. The 'other edge' of the domain with respect to the LSP path is
node-k, where k is the smallest number greater than i+1 such that
lt-k is compatible with lt-i.
Note that the concept of 'domain' introduced above has to do with
link types, but has nothing to do with routing domains.
4.3.2. LSP aggregation
LSP aggregation is controlled by the LSRs at the edges of a domain.
The aggregation is accomplished by establishing LSPs that span the
domain, and start and end at the edges of that domain. The edge LSRs
then use these LSPs for (a) creating forwarding adjacencies, and for
(b) nesting of other LSPs that are established and terminated at LSRs
beyond the domain and its edges.
Note that a 'normal' packet-switched LSP may only be nested in an
FA-LSP of type FA-PSC; a SONET trail may only be nested in an FA-LSP
of type FA-TDM; and an optical trail may only be nested in an FA-LSP
of type FA-LSC.
Establishment/termination of the LSPs that span a domain could be
triggered either by mechanisms outside of MPLS (e.g., via
administrative control), or by mechanisms within MPLS (e.g., as a
result of the LSR at the edge of a domain domain receiving LSP setup
requests originated by some other LSRs beyond the domain and its
edges. Procedures described in Section 4.3.3 applied to both cases.
Kompella/Rekhter et al
[Page 11]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
Procedures described in Section 4.3.4 apply only to the latter case.
4.3.3. Common procedures
For the purpose of processing the ERO in a Path message of an LSP
that is to be tunneled over a forwarding adjacency, an LSR at the
head-end of the FA-LSP views the LSR at the tail of that FA-LSP as
adjacent (one IP hop away).
If the LSR at the tail of the FA-LSP is capable of packet switching,
the Path message for the tunneled LSP can itself be tunneled over the
FA-LSP. If the encapsulation on the carrier LSP can distinguish IP
from MPLS, the Path message is sent as a plain IP packet. Otherwise,
the Path message is sent with a label of 0, meaning "pop the label
and treat as IP".
If the LSR at the tail of the FA-LSP is not capable of packet
switching, the Path message is unicast over the control plane to the
tail of the carrier LSP, without the Router Alert option.
The Resv message back to the head-end of the FA-LSP (PHOP) cannot be
sent over the same FA-LSP as it is unidirectional. The Resv message
can either take any LSP whose end-point is the head-end of the FA-
LSP, or be unicast over the control plane to the head-end.
When an LSP is tunneled through an FA-LSP, the LSR at the head-end of
the FA-LSP subtracts the LSP's bandwidth from the unreserved
bandwidth of the forwarding adjacency.
4.3.4. Specific procedures
When an LSR receives a Path message, the LSR determines whether it is
at the edge of a domain with respect to the ERO carried in the
message. The LSR does this by looking up the link types of the
previous hop and the next hop in its IGP database, and comparing them
using the relation defined in section 4.3.1. If the LSR is not at
the edge of a domain, the procedures in this section do not apply.
If the LSR is at the edge of a domain, it must then determine the
other edge of the domain with respect to the ERO, again using the IGP
database. The LSR then extracts the strict hop subsequence from
itself to the other end of the domain.
The LSR then compares the strict hop subsequence with all existing
FA-LSPs originated by the LSR; if a match is found, and that FA-LSP
Kompella/Rekhter et al
[Page 12]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
has enough unreserved bandwidth for the LSP being signaled, the LSR
uses that FA-LSP as follows. The Path message for the original LSP is
sent to the egress of the FA-LSP, not to the next hop along the FA-
LSP's path. The PHOP in the message is the address of the LSR at the
head-end of the FA-LSP. Before sending the Path message, the ERO in
that message is adjusted by removing the subsequence of the ERO that
lies in the FA-LSP, and replacing it with just the end point of the
FA-LSP.
Otherwise (if no existing FA-LSP is found), the LSR sets up a new
FA-LSP. That is, it initiates (using RSVP) a new LSP setup just for
the FA-LSP.
After the LSR establishes the new FA-LSP, the LSR announces this LSP
into IS-IS/OSPF as a forwarding adjacency.
The unreserved bandwidth of the forwarding adjacency is computed by
subtracting the bandwidth of sessions pending the establishment of
the FA-LSP associated from the bandwidth of the FA-LSP.
An FA-LSP could be torn down by the LSR at the head-end of the FA-LSP
as a matter of policy local to the LSR. It is expected that the FA-
LSP would be torn down once there are no more LSPs carried by the
FA-LSP. When the FA-LSP is torn down, the forwarding adjacency
associated with the FA-LSP is no longer advertised into IS-IS/OSPF.
5. Bandwidth accounting on OXCs
As mentioned above, an IP link consists of a control channel and a
set of fibers. Initially, for each fiber the administrator sets up
how many lambdas could be reserved at each priority on that fiber,
and the Link Media type(s) supported by the fiber. For an IP link,
the unreserved bandwidth at each priority level is determined by
adding up the bandwidths of all the lambdas of all the fibers in the
IP link at that priority level. The Link Media Type of the IP link
is the set union of the Link Media Types of each fiber in the link.
Note that while the IP link contains the aggregated information, RSVP
needs to track the unaggregated information, i.e., the available
lambdas for each fiber.
Suppose, in response to a previously sent Path message, a Resv
message is received at an ingress or intermediate OXC of an optical
trail, along with the lambda and fiber to use, say <L, F>. Say
lambda L has bandwidth B and Link Media Type M. RSVP must remove L
from the list of available lambdas for fiber F. Furthermore, the
unreserved bandwidth at the holding priority of the optical trail is
Kompella/Rekhter et al
[Page 13]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
reduced by B. Also, if after lambda L is removed, there are no more
available lambdas with Link Media Type M in the fiber set that F
belongs to, M is removed from the list of Link Media Types for the
link containing F. Finally, the bandwidth accounting procedures for
link bundles [Kompella] may also apply.
When an optical trail that was using lambda L of fiber F at an
ingress or intermediate OXC is torn down, that OXC needs to mark L as
available. The unreserved bandwidth (at the holding priority of the
optical trail) of the IP link to which fiber F belongs is increased
by the bandwidth of lambda L, and the Link Media Type of lambda L is
added to the list of Link Media Types for the IP link if not already
present. Finally, the accounting procedures for link bundles may
also apply.
6. Security Considerations
This document raises no new security issues for IS-IS, OSPF or RSVP.
7. Acknowledgements
We would like to thank Der-Hwa Gan, Jim Gibson, Robert Goguen, George
Swallow, and Quaizar Vohra for their review and comments.
8. References
[Awduche-1] Awduche, D., Rekhter, Y., Drake, J., Coltun, R., "Multi-
Protocol Lambda Switching: Combining MPLS Traffic Engineering Control
With Optical Crossconnects", draft-awduche-mpls-te-optical-01.txt
[Awduche-2] Awduche, D., Berger, L., Gan, D-H., Li, T., Swallow, G.,
Srinivasan, V., "Extensions to RSVP for LSP Tunnels", draft-ietf-
mpls-rsvp-lsp-tunnel-04.txt
[Basak] Basak, D., Awduche, D., Drake, J., Rekhter, Y., "Multi-
protocol Lambda Switching: Issues in Combining MPLS Traffic
Engineering Control With Optical Crossconnects", draft-basak-mpls-
oxc-issues-00.txt
[Smit] Smit, H., Li, T., "IS-IS extensions for Traffic Engineering",
draft-ietf-isis-traffic-01.txt
[Katz] Katz, D., Yeung, D., "Traffic Engineering Extensions to OSPF",
draft-katz-yeung-ospf-traffic-01.txt
Kompella/Rekhter et al
[Page 14]
Internet Draft draft-kompella-mpls-optical.txt Februrary 2000
[Kompella] Kompella, K., Rekhter, Y., "Link Bundling in MPLS Traffic
Engineering", draft-kompella-mpls-bundle-00.txt
9. Author Information
Kireeti Kompella Yakov Rekhter
Juniper Networks, Inc. Cisco Systems, Inc.
385 Ravendale Drive 170 West Tasman Drive
Mountain View, CA 94043 San Jose, CA 95134
email: kireeti@juniper.net email: yakov@cisco.com
Daniel O. Awduche Alan Hannan
UUNET (MCI Worldcom) Global Crossing
22001 Loudoun County Parkway 141 Caspian Court
Ashburn, VA 20147 Sunnyvale, CA 94087
email: awduche@uu.net email: alan@gblx.net
Gisli Hjalmtysson Joe Lawrence
AT&T Labs - Research Level 3 Communications
180 Park Avenue 1025 Eldorado Boulevard
Florham Park, NJ 07932 Broomfied CO, 80021
email: gisli@research.att.com email: joe.lawrence@level3.com
Satoru Okamoto Debashis Basak
NTT Network Innovation Laboratories Marconi
Room 807A, 1-1 Hikari-no-oka, 1000 FORE Drive
Yokosuka-shi, Kanagawa 239-0847 Japan Warrendale, PA 15086-7502
email: okamoto@exa.onlab.ntt.co.jp email: dbasak@fore.com
Greg Bernstein John Drake
Ciena Corporation Chromisys
10201 Bubb Road 1012 Stuart Drive
Cupertino, CA 95014 Sunnyvale, CA 94086
email: GregB@ciena.com email:jdrake@chromisys.com
Near Margalit Ed Stern
New Access Communications Sirocco Systems
71 Vista Montana 95 Barnes Rd.
San Jose CA 95134 Wallingford, CT 06492
email: margalit@new-access.com email:ed.stern@siroccosystems.com
Kompella/Rekhter et al
[Page 15]
Html markup produced by rfcmarkup 1.111, available from
https://tools.ietf.org/tools/rfcmarkup/