draft-ietf-isis-gmpls-extensions-00.txt   draft-ietf-isis-gmpls-extensions-01.txt 
Network Working Group K. Kompella (Juniper Networks) Network Working Group K. Kompella (Juniper Networks)
Internet Draft Y. Rekhter (Cisco Systems) Internet Draft Y. Rekhter (Cisco Systems)
Expiration Date: March 2001 A. Banerjee (Calient Networks) Expiration Date: May 2001 A. Banerjee (Calient Networks)
J. Drake (Calient Networks) J. Drake (Calient Networks)
G. Bernstein (Ciena) G. Bernstein (Ciena)
D. Fedyk (Nortel Networks) D. Fedyk (Nortel Networks)
E. Mannie (GTS Network) E. Mannie (GTS Network)
D. Saha (Tellium) D. Saha (Tellium)
V. Sharma (Tellabs) V. Sharma (Tellabs)
IS-IS Extensions in Support of Generalized MPLS IS-IS Extensions in Support of Generalized MPLS
draft-ietf-isis-gmpls-extensions-00.txt draft-ietf-isis-gmpls-extensions-01.txt
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Engineering. Some of these enhancements also need to be carried in Engineering. Some of these enhancements also need to be carried in
the signaling protocols [6]. the signaling protocols [6].
The organization of the remainder of the document is as follows. In The organization of the remainder of the document is as follows. In
Section 4, we describe the types of links that may be advertised in Section 4, we describe the types of links that may be advertised in
IS-IS TE LSAs (we call Link State PDUs LSAs to avoid confusion with IS-IS TE LSAs (we call Link State PDUs LSAs to avoid confusion with
Label Switched Paths). In Section 5, we define a new set of Label Switched Paths). In Section 5, we define a new set of
Type/Length/Value (TLV) triplets, as well as extend a proposed TLV, Type/Length/Value (TLV) triplets, as well as extend a proposed TLV,
and describe their formats. and describe their formats.
4. GMPLS Links 4. GMPLS TE Links
In this section we describe the various types of links that can be
announced in IS-IS TE LSAs, namely, normal links, non-packet links,
and forwarding adjacencies.
4.1. Normal links
If the nodes on both ends of a link can send and receive on a packet-
by-packet basis, this link is a normal link. Control packets (IS-IS
protocol packets and signaling packets) and data packets can be sent
over the link, so nothing special needs to be done.
4.2. Non-packet links Traditionally, a TE link is advertised as an adjunct to a "regular"
IS-IS link, i.e., an IS-IS adjacency is brought up on the link, and
when the link is up, both the regular SPF properties of the link
(basically, the SPF metric) and the TE properties of the link are
then advertised.
If either node on the end of a bi-directional link cannot However, GMPLS challenges this notion in three ways. First, links
multiplex/demultiplex individual packets on that link (see [5]) then that are not capable of sending and receiving on a packet-by-packet
that link cannot be used for sending IS-IS hellos and LSAs. In this basis may yet have TE properties; however, an IS-IS adjacency cannot
case, a proxy control channel is needed for sending and receiving be brought up on such links. Second, a Label Switched Path can be
control packets. From IS-IS's point of view, the combination of the advertised as a point-to-point TE link (see [LSP-HIER]); thus, an
data link (in the context of this document, a non-packet link is also advertised TE link need no longer be between two IS-IS neighbors.
called a bearer channel) and the control channel is a single link; Finally, a number of links may be advertised as a single TE link
the TE attributes associated with this link are those of the bearer (perhaps for improved scalability), so again, there is no longer a
channel, but are sent over the control channel. one-to-one association of a regular adjacency and a TE link.
The association of a bearer channel with a control channel is by Thus we have a more general notion of a TE link. A TE link is a
configuration. Note that for a bearer channel D to be associated "logical" link that has TE properties, some of which may be
with a control channel C, D and C should have the same end points, configured on the advertising Label Switching Router (LSR), others
and that the same association must be made at both ends. The means which may be obtained from other LSRs by means of some protocol, and
by which it is verified that the two ends have the same associations yet others which may be deduced from the component(s) of the TE link.
is outside the scope of this document, however, see [7]. A TE link between a pair of LSRs doesn't imply the existence of an
IS-IS adjacency between these LSRs. A TE link must also have some
means by which the advertising LSR can know of its liveness (this
means may be IS-IS hellos, but is not limited to IS-IS 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) IS-
IS neighbors using the TE TLVs. In this document, we call the
interfaces over which regular IS-IS adjacencies are established
"control channels".
If there are several non-packet links between the same pair of nodes, [3] defines the canonical TE properties, and says how to associate TE
the associated control channels may be logical interfaces over the properties to regular (packet-switched) links. This document extends
same physical control link. 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). [5] says how to associate TE
properties with Label Switched Paths; [4] says how to associate TE
properties with a "bundle" of links.
4.2.1. Excluding data traffic from control channels 4.1. Excluding data traffic from control channels
The control channels between nodes in a GMPLS network, such as The control channels between nodes in a GMPLS network, such as OXCs
optical cross-connects (OXCs) (see [1], [2]), SONET cross-connects (see [1], [2]), SONET cross-connects and/or routers, are generally
and/or routers, are generally meant for control and administrative meant for control and administrative traffic. These control channels
traffic. These control channels are advertised into IS-IS as normal are advertised into IS-IS as normal IS links as mentioned in the
IS links as mentioned in the previous section; this allows the previous section; this allows the routing of (for example) RSVP
routing of (for example) RSVP messages and telnet sessions. However, messages and telnet sessions. However, if routers on the edge of the
if routers on the edge of the optical domain attempt to forward data optical domain attempt to forward data traffic over these channels,
traffic over these channels, the channel capacity will quickly be the channel capacity will quickly be exhausted.
exhausted.
If one assumes that data traffic is sent to BGP destinations, and If one assumes that data traffic is sent to BGP destinations, and
control traffic to IGP destinations, then one can exclude data control traffic to IGP destinations, then one can exclude data
traffic from the control plane by restricting BGP nexthop resolution. traffic from the control plane by restricting BGP nexthop resolution.
(It is assumed that OXCs are not BGP speakers.) Suppose that a (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 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 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 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 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 the interface I. If it does, and the link is not packet-switch
capable (see [5]), R installs a discard route for destination D. capable (see [5]), R installs a discard route for destination D.
Otherwise, R installs (as usual) a route for destination D with 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- 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 switch incapable links; if all of its links are packet-switch
capable, then clearly this check is redundant. capable, then clearly this check is redundant.
Other techniques for excluding data traffic from control channels may Other techniques for excluding data traffic from control channels may
also be needed. also be needed.
4.3. Forwarding Adjacency
An LSR uses MPLS TE procedures to create and maintain an LSP. The
LSR then may (under its local configuration control) to announce this
LSP as a link into IS-IS. When this link is advertised into the same
instance of IS-IS as the one that determines the route taken by the
LSP, we call such a link a "forwarding adjacency" (FA). For details
about FAs (for example, their TE properties, the methodology for
their use in constrained SPF path computation, etc) see [5].
4.4. Link Bundling
For each type of link just described, it is possible to "bundle"
several links together, i.e., treat them as a single link from IS-
IS's point of view. For example, several normal links can be
advertised as a single normal link.
The mechanisms for bundling, including the restrictions on when links
can be bundled and the TE attributes of the bundle are described in
[4].
5. IS-IS Routing Enhancements 5. IS-IS Routing Enhancements
In this section we define the routing enhancements on the various In this section we define the enhancements to the TE properties of
types of links that can be announced in IS-IS TE LSAs, namely, normal GMPLS TE links that can be announced in IS-IS TE LSAs. In this
links, non-packet links, and forwarding adjacencies. In this
document, we enhance the sub-TLVs for the extended IS reachability document, we enhance the sub-TLVs for the extended IS reachability
TLV (see [3]) in support of GMPLS. Specifically, we add the TLV (see [3]) in support of GMPLS. Specifically, we add sub-TLVs
following sub-TLV: for: Outgoing/Incoming Interface Identifier, Maximum LSP Bandwidth
and Link Protection Type. This brings the list of sub-TLVs of the
extended IS reachability TLV to:
Sub-TLV Type Length Name Sub-TLV Type Length Name
20 1 Link Protection Type 3 4 Administrative group (color)
4 4 Outgoing Interface Identifier
5 4 Incoming Interface Identifier
6 4 IPv4 interface address
8 4 IPv4 neighbor address
9 4 Maximum link bandwidth
10 4 Reservable link bandwidth
11 32 Unreserved bandwidth
12 32 Maximum LSP Bandwidth
18 3 TE Default metric
19 1 Link Mux Capability
20 2 Link Protection Type
250-254 - Reserved for cisco specific extensions
255 - Reserved for future expansion
We further add two new TLVs. We further add two new TLVs.
TLV Type Length Name TLV Type Length Name
136 (TBD) variable Link Descriptor 136 (TBD) variable Link Descriptor
138 (TBD) variable Shared Risk Link Group 138 (TBD) variable Shared Risk Link Group
5.1. Link Protection Type sub-TLV 5.1. Outgoing Interface Identifier
A link from LSR A to LSR B may be assigned an "outgoing interface
identifier". This identifier is a non-zero 32-but number that is
assigned by LSR A. This identifier must be unique within the scope
of A. If such an identifier has been assigned, A can advertise it as
a sub-TLV of the extended IS reachability TLV with type 4, length 4
and value equal to the assigned identifier.
5.2. Incoming Interface Identifier
Suppose there is a link L from A to B. Suppose further that the link
L' from B to A that corresponds to the same interface as L has been
assigned an outgoing interface identifier by B. The "incoming
interface identifier" for L (from A's point of view) is defined as
the outgoing interface identifier for L' (from B's point of view).
If A knows this value (by means beyond the scope of this document), A
can advertise it as a sub-TLV of the extended IS reachability TLV
with type 5, length 4 and value equal to L's incoming interface
identifier.
5.3. Maximum LSP Bandwidth sub-TLV
The Maximum LSP Bandwidth takes the place of the Maximum Link
Bandwidth. However, while Maximum Link Bandwidth is a single fixed
value (usually simply the link capacity), Maximum LSP Bandwidth is
carried per priority, and may vary as LSPs are set up and torn down.
The Maximum LSP Bandwidth of a bundled link at priority p is defined
to be the maximum of the Maximum LSP Bandwidth at priority p of each
component link.
If a component link is a simple (unbundled) link, define its Maximum
LSP Bandwidth at priority p to be the smaller of its unreserved
bandwidth at priority p and its maximum link bandwidth.
The Maximum LSP Bandwidth TLV has type 12 and length 32 octets. The
value is a list of eight 4 octet fields in IEEE floating point format
of the Maximum LSP Bandwidth of the link, with priority 0 first and
priority 7 last.
Although Maximum Link Bandwidth is to be deprecated, for backward
compatibility, one MAY set the Maximum Link Bandwidth to the Maximum
LSP Bandwidth at priority 7 of the link.
5.4. Link Protection Type sub-TLV
The Link Protection Type sub-TLV represents the protection capability The Link Protection Type sub-TLV represents the protection capability
that exists on a link. It is desirable to carry this information so that exists on a link. It is desirable to carry this information so
that it may be used by the path computation algorithm to set up LSPs that it may be used by the path computation algorithm to set up LSPs
with appropriate protection characteristics. This is a sub-TLV (of with appropriate protection characteristics. This is a sub-TLV (of
type 20) of the extended IS reachability TLV (type 22) as defined in type 20) of the extended IS reachability TLV, with length two octets,
[3]. the first of which can take one of the following values:
If the link has 1+1 protection, it means that a disjoint backup Value Link Protection Type
bearer channel is reserved and dedicated for protecting the primary 0 Unprotected
bearer channel. This backup bearer channel is not shared by any 1 Shared
other connection, and traffic is duplicated and carried 2 Dedicated 1:1
simultaneously over both channels. 3 Dedicated 1+1
4 Enhanced
If the link has 1:N protection, it means that for N primary bearer If the link is Unprotected, it means that there is no backup link for
channels, there is one disjoint backup bearer channel reserved to traffic being carried on the link.
carry the traffic. Additionally, the protection bearer channel MAY
carry low-priority preemptable traffic. The bandwidth of backup
bearer channels will be announced in the unreserved bandwidth sub-TLV
at the appropriate priority.
If the link has ring protection, it means that the primary bearer If the link has Shared protection, it means that for the N > 1
channel is protected by the presence of an alternate link possibly primary data-bearing channels, there are M disjoint backup data-
using other links and nodes in the network. bearing channels reserved to carry the traffic. Additionally, the
protection data-bearing channel MAY carry low-priority preemptable
traffic. The bandwidth of backup data-bearing channels will be
announced in the unreserved bandwidth sub-TLV at the appropriate
priority.
The Link Protection Type sub-TLV has a length of two octets, the If the link has Dedicated 1:1 protection, it means that for each
first of which can take one of the following values: primary data-bearing channel, there is one disjoint backup data-
bearing channel reserved to carry the traffic. Additionally, the
protection data-bearing channel MAY carry low-priority preemptable
traffic. The bandwidth of backup data-bearing channels will be
announced in the unreserved bandwidth sub-TLV at the appropriate
priority.
Value Link Protection Type If the link has Dedicated 1+1 protection, it means that a disjoint
0 Reserved (see signaling draft [6]) backup data-bearing channel is reserved and dedicated for protecting
1 None the primary data-bearing channel. This backup data-bearing channel
2 1+1 is not shared by any other connection, and traffic is duplicated and
3 1:N carried simultaneously over both channels.
4 Ring
The second octet gives a priority value, such that a new connection If the link has Enhanced protection, it indicates that the protection
with a priority value higher than this value is guaranteed to be scheme for the link is more reliable than the Dedicated 1+1, e.g., 4
setup on a primary (or working) channel, and not on a secondary (or fiber BLSR/MS-SPRING.
protect) channel.
The second octet gives a priority value such that a new connection
with a higher priority (i.e., numerically lower than this value) is
guaranteed to be setup on a primary (or working) channel, and not on
a secondary (or protect) channel.
The Link Protection Type sub-TLV is optional and if an LSA does not The Link Protection Type sub-TLV is optional and if an LSA does not
carry the TLV, then the Link Protection Type is unknown. carry the TLV, then the Link Protection Type is unknown. The
protection capability of a link is typically pre-configured and does
not change dynamically over time. The working priority value is pre-
configured and does not depend on the traffic characteristics on the
primary data-bearing channel.
5.2. Link Descriptor TLV 5.5. Link Descriptor TLV
The Link Descriptor TLV represents the characteristics of the link, The Link Descriptor TLV represents the characteristics of the link,
in particular the link type and the bit transmission rate. These in particular the link type and the bit transmission rate. These
characteristics represent one of the constraints on the type of LSPs characteristics represent one of the constraints on the type of LSPs
that could be carried over a link. that could be carried over a link.
These characteristics should not be confused with the physical link These characteristics should not be confused with the physical link
encoding or multiplex structure (if any). For example there are encoding or multiplex structure (if any). For example there are
systems where four OC-48s are switched and transported over a single systems where four OC-48s are switched and transported over a single
fiber via wavelength division multiplexing (WDM) technology. There fiber via wavelength division multiplexing (WDM) technology. There
skipping to change at page 7, line 5 skipping to change at page 8, line 5
2 Arbitrary SONET 2 Arbitrary SONET
3 Standard SDH 3 Standard SDH
4 Arbitrary SDH 4 Arbitrary SDH
5 Clear 5 Clear
6 GigE 6 GigE
7 10GigE 7 10GigE
A link having Standard SONET (or Standard SDH) link encoding type can A link having Standard SONET (or Standard SDH) link encoding type can
switch data at a minimum rate, which is given by the Minimum switch data at a minimum rate, which is given by the Minimum
Reservable Bandwidth on that link, and the maximum rate is given by Reservable Bandwidth on that link, and the maximum rate is given by
the Maximum Reservable Bandwidth on that link. In other words, the the Maximum Reservable Bandwidth on that link. Typical values of
Minimum and Maximum Reservable Bandwidth represents the leaf and the these are enumerated in the GMPLS signaling draft [6]. In other
root of one branch within the structure of the SONET (or SDH) words, the Minimum and Maximum Reservable Bandwidth represents the
hierarchy. An LSP on that link may reserve any bit transmission rate leaf and the root of one branch within the structure of the SONET (or
that is allowed by the SONET (or SDH) hierarchy between the minimum SDH) hierarchy. An LSP on that link may reserve any bit transmission
and maximum reservable values (the spectrum is discrete). For rate that is allowed by the SONET (or SDH) hierarchy between the
example, consider a branch of SONET multiplexing tree : VT-1.5, minimum and maximum reservable values (the spectrum is discrete).
For example, consider a branch of SONET multiplexing tree : VT-1.5,
STS-1, STS-3c, STS-12c, STS-48c, STS-192c. If it is possible to STS-1, STS-3c, STS-12c, STS-48c, STS-192c. If it is possible to
establish all these connections on a OC-192 link, it can be establish all these connections on a OC-192 link, it can be
advertised as follows: Minimum Reservable Bandwidth VT-1.5 and advertised as follows: Minimum Reservable Bandwidth VT-1.5 and
Maximum Reservable Bandwidth STS-192. Maximum Reservable Bandwidth STS-192.
A link having Arbitrary SONET (or Arbitrary SDH) link encoding type A link having Arbitrary SONET (or Arbitrary SDH) link encoding type
can switch data at a minimum rate, which is given by the Minimum can switch data at a minimum rate, which is given by the Minimum
Reservable Bandwidth on that link, and the maximum rate is given by Reservable Bandwidth on that link, and the maximum rate is given by
the Maximum Reservable Bandwidth on that link. An LSP on that link the Maximum Reservable Bandwidth on that link. Typical values of
may reserve any bit transmission rate that is a multiple of the these are enumerated in the GMPLS signaling draft [6]. An LSP on
Minimum Reservable Bandwidth between the minimum and maximum that link may reserve any bit transmission rate that is a multiple of
the Minimum Reservable Bandwidth between the minimum and maximum
reservable values (the spectrum is discrete). reservable values (the spectrum is discrete).
To handle the case where a link could support multiple branches of To handle the case where a link could support multiple branches of
the SONET (or SDH) multiplexing hierarchy, one could use multiple LSP the SONET (or SDH) multiplexing hierarchy, one could use multiple LSP
descriptors. For example, if a link supports VT-1.5 and VT-2 (which descriptors. For example, if a link supports VT-1.5 and VT-2 (which
are not part of same branch of SONET multiplexing tree), then it are not part of same branch of SONET multiplexing tree), then it
could advertise two LSP descriptors one for each one. could advertise two LSP descriptors, one for each one.
For a link with Clear encoding, the minimum and maximum reservable For a link with Clear encoding, the minimum and maximum reservable
bandwidth will imply that the optical path is tuned to carry traffic bandwidth will imply that the optical path is tuned to carry traffic
within those range of values. (Note that it should be possible to within those range of values. (Note that it should be possible to
carry OC-x as well as GigE or any other encoding format, as long as carry OC-x as well as GigE or any other encoding format, as long as
the bit transmission rate of the data to be carried is within this the bit transmission rate of the data to be carried is within this
range). range.)
For other encoding types, the minimum and maximum reservable For other encoding types, the minimum and maximum reservable
bandwidth should be set to have the same values. bandwidth should be set to have the same values.
Link Descriptors present a new constraint for LSP path computation. Link Descriptors present a new constraint for LSP path computation.
On a bundled link we assume that either the whole link is configured On a bundled link we assume that either the whole link is configured
with the Link Descriptor Types, or each of its component links are with the Link Descriptor Types, or each of its component links are
configured with the Link Descriptor Types. In the latter case, the configured with the Link Descriptor Types. In the latter case, the
Link Descriptor Type of the bundled link is set to the set union of Link Descriptor Type of the bundled link is set to the set union of
skipping to change at page 8, line 24 skipping to change at page 9, line 26
Link Descriptor remains the same until the node can no longer Link Descriptor remains the same until the node can no longer
establish a STS-48c LSP over the link (which means that at this point establish a STS-48c LSP over the link (which means that at this point
more than 144 time slots are taken by LSPs on the link). Once this more than 144 time slots are taken by LSPs on the link). Once this
happened, the Link Descriptor is modified again, and the modified happened, the Link Descriptor is modified again, and the modified
Link Descriptor is advertised to other nodes. Link Descriptor is advertised to other nodes.
Note that changes to the Link Descriptor TLV will also affect the Note that changes to the Link Descriptor TLV will also affect the
Unreserved Bandwidth sub-TLV with respect to bandwidth available on Unreserved Bandwidth sub-TLV with respect to bandwidth available on
the link. the link.
5.3. Shared Risk Link Group TLV 5.6. Shared Risk Link Group TLV
A set of links may constitute a 'shared risk link group' (SRLG) if 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. 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 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 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 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. identified by a 32 bit number that is unique within an IGP domain.
The SRLG of a LSP is the union of the SRLGs of the links in the LSP. 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 The SRLG of a bundled link is the union of the SRLGs of all the
skipping to change at page 9, line 36 skipping to change at page 10, line 38
[2] Basak, D., Awduche, D., Drake, J., Rekhter, Y., "Multi- [2] Basak, D., Awduche, D., Drake, J., Rekhter, Y., "Multi-
protocol Lambda Switching: Issues in Combining MPLS Traffic protocol Lambda Switching: Issues in Combining MPLS Traffic
Engineering Control With Optical Crossconnects", Engineering Control With Optical Crossconnects",
draft-basak-mpls-oxc-issues-01.txt (work in progress) draft-basak-mpls-oxc-issues-01.txt (work in progress)
[3] Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering", [3] Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering",
draft-ietf-isis-traffic-02.txt (work in progress) draft-ietf-isis-traffic-02.txt (work in progress)
[4] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS [4] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling in MPLS
Traffic Engineering", draft-kompella-mpls-bundle-02.txt (work Traffic Engineering", draft-kompella-mpls-bundle-04.txt (work
in progress) in progress)
[5] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE", [5] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE",
draft-ietf-mpls-lsp-hierarchy-00.txt (work in progress) draft-ietf-mpls-lsp-hierarchy-00.txt (work in progress)
[6] Optical MPLS Group, "MPLS Optical/Switching Signaling Functional [6] Generalized MPLS Group, "Generalized MPLS - Signaling Functional
Description" (work in progress) Description", draft-ietf-mpls-generalized-signaling-01.txt (work
in progress)
[7] Lang J., Mitra K., Drake J., Kompella K., Rekhter Y., Berger L., [7] Lang J., Mitra K., Drake J., Kompella K., Rekhter Y., Berger L.,
Saha, D., Sandick, H., and Basak D., "Link Management Protocol", Saha, D., Sandick, H., and Basak D., "Link Management Protocol",
draft-lang-mpls-lmp-01.txt (work in progress) draft-ietf-mpls-lmp-01.txt (work in progress)
9. Authors' Information 9. Authors' Information
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave 1194 N. Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: kireeti@juniper.net Email: kireeti@juniper.net
Yakov Rekhter Yakov Rekhter
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/