draft-ietf-ccamp-gmpls-routing-04.txt   draft-ietf-ccamp-gmpls-routing-05.txt 
Network Working Group K. Kompella (Juniper Networks) Network Working Group K. Kompella (Editor)
Internet Draft Y. Rekhter (Juniper Networks) Internet Draft Y. Rekhter (Editor)
Expiration Date: October 2002 A. Banerjee (Calient Networks) Category: Standards Track Juniper Networks
J. Drake (Calient Networks) Expires: February 2003 August 2002
G. Bernstein (Ciena)
D. Fedyk (Nortel Networks)
E. Mannie (GTS Network)
D. Saha (Tellium)
V. Sharma (Metanoia, Inc.)
D. Basak (AcceLight Networks)
L. Berger (Movaz Networks)
Routing Extensions in Support of Generalized MPLS Routing Extensions in Support of Generalized MPLS
draft-ietf-ccamp-gmpls-routing-04.txt draft-ietf-ccamp-gmpls-routing-05.txt
1. Status of this Memo 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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
2. Abstract Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document specifies routing extensions in support of Generalized This document specifies routing extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS). Multi-Protocol Label Switching (GMPLS).
3. Summary for Sub-IP Area Summary for Sub-IP Area
3.1. Summary (This section to be removed before publication.)
0.1. Summary
This document specifies routing extensions in support of Generalized This document specifies routing extensions in support of Generalized
Multi-Protocol Label Switching (GMPLS). Multi-Protocol Label Switching (GMPLS).
3.2. Where does it fit in the Picture of the Sub-IP Work 0.2. Where does it fit in the Picture of the Sub-IP Work
This work fits squarely in the CCAMP box. This work fits squarely in the CCAMP box.
3.3. Why is it Targeted at this WG 0.3. Why is it Targeted at this WG
This draft is targeted at the CCAMP WG, because this draft specifies This draft is targeted at the CCAMP WG, because this draft specifies
the extensions to the link state routing protocols in support of the extensions to the link state routing protocols in support of
GMPLS, and because GMPLS is within the scope of CCAMP WG. GMPLS, and because GMPLS is within the scope of CCAMP WG.
3.4. Justification 0.4. Justification
The WG should consider this document as it specifies the extensions The WG should consider this document as it specifies the extensions
to the link state routing protocols in support of GMPLS. to the link state routing protocols in support of GMPLS.
4. Introduction 1. Specification of Requirements
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 RFC 2119 [RFC2119].
2. Introduction
This document specifies routing extensions in support of carrying This document specifies routing extensions in support of carrying
link state information for Generalized Multi-Protocol Label Switching link state information for Generalized Multi-Protocol Label Switching
(GMPLS). This document enhances the routing extensions [ISIS-TE], (GMPLS). This document enhances the routing extensions [ISIS-TE],
[OSPF-TE] required to support MPLS Traffic Engineering. [OSPF-TE] required to support MPLS Traffic Engineering.
5. GMPLS TE Links 3. GMPLS TE Links
Traditionally, a TE link is advertised as an adjunct to a "regular" 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 link, i.e., a routing adjacency is brought up on the link, and when
the link is up, both the regular SPF properties of the link the link is up, both the regular SPF properties of the link
(basically, the SPF metric) and the TE properties of the link are (basically, the SPF metric) and the TE properties of the link are
then advertised. then advertised.
GMPLS challenges this notion in three ways. First, links that are GMPLS challenges this notion in three ways. First, links that are
not capable of sending and receiving on a packet-by-packet basis may not capable of sending and receiving on a packet-by-packet basis may
yet have TE properties; however, a routing adjacency cannot be yet have TE properties; however, a routing adjacency cannot be
skipping to change at page 4, line 21 skipping to change at page 4, line 29
In this document, we call the interfaces over which regular routing In this document, we call the interfaces over which regular routing
adjacencies are established "control channels". adjacencies are established "control channels".
[ISIS-TE] and [OSFP-TE] define the canonical TE properties, and say [ISIS-TE] and [OSFP-TE] define the canonical TE properties, and say
how to associate TE properties to regular (packet-switched) links. how to associate TE properties to regular (packet-switched) links.
This document extends the set of TE properties, and also says how to This document extends the set of TE properties, and also says how to
associate TE properties with non-packet-switched links such as links associate TE properties with non-packet-switched links such as links
between Optical Cross-Connects (OXCs). [LSP-HIER] says how to between Optical Cross-Connects (OXCs). [LSP-HIER] says how to
associate TE properties with links formed by Label Switched Paths. associate TE properties with links formed by Label Switched Paths.
5.1. Excluding data traffic from control channels 3.1. Excluding data traffic from control channels
The control channels between nodes in a GMPLS network, such as OXCs, The control channels between nodes in a GMPLS network, such as OXCs,
SDH cross-connects and/or routers, are generally meant for control SDH cross-connects and/or routers, are generally meant for control
and administrative traffic. These control channels are advertised and administrative traffic. These control channels are advertised
into routing as normal links as mentioned in the previous section; into routing as normal links as mentioned in the previous section;
this allows the routing of (for example) RSVP messages and telnet this allows the routing of (for example) RSVP messages and telnet
sessions. However, if routers on the edge of the optical domain sessions. However, if routers on the edge of the optical domain
attempt to forward data traffic over these channels, the channel attempt to forward data traffic over these channels, the channel
capacity will quickly be exhausted. capacity will quickly be exhausted.
skipping to change at page 5, line 14 skipping to change at page 5, line 22
in another portion of the GMPLS network. For example, the 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 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 to expose the internals of the addressing or topology. In such a
network the control channels are never advertised into the end data network the control channels are never advertised into the end data
network. In this instance, independent mechanisms are used to network. In this instance, independent mechanisms are used to
advertise the data addresses over the carrier network. advertise the data addresses over the carrier network.
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.
6. GMPLS Routing Enhancements 4. GMPLS Routing Enhancements
In this section we define the enhancements to the TE properties of 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 TE links. Encoding of this information in IS-IS is specified in
[GMPLS-ISIS]. Encoding of this information in OSPF is specified in [GMPLS-ISIS]. Encoding of this information in OSPF is specified in
[GMPLS-OSPF]. [GMPLS-OSPF].
6.1. Support for unnumbered links 4.1. Support for unnumbered links
An unnumbered link has to be a point-to-point link. An LSR at each 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 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 identifier is a non-zero 32-bit number that is unique within the
scope of the LSR that assigns it. scope of the LSR that assigns it.
Consider an (unnumbered) link between LSRs A and B. LSR A chooses an Consider an (unnumbered) link between LSRs A and B. LSR A chooses an
idenfitier for that link. So is LSR B. From A's perspective we refer idenfitier for that link. So is LSR B. From A's perspective we refer
to the identifier that A assigned to the link as the "link local to the identifier that A assigned to the link as the "link local
identifier" (or just "local identifier"), and to the identifier that identifier" (or just "local identifier"), and to the identifier that
skipping to change at page 6, line 5 skipping to change at page 6, line 5
that B assigned to the link is the local identifier, and the that B assigned to the link is the local identifier, and the
identifier that A assigned to the link is the remote identifier. identifier that A assigned to the link is the remote identifier.
Support for unnumbered links in routing includes carrying information Support for unnumbered links in routing includes carrying information
about the identifiers of that link. Specifically, when an LSR about the identifiers of that link. Specifically, when an LSR
advertises an unnumbered TE link, the advertisement carries both the advertises an unnumbered TE link, the advertisement carries both the
local and the remote identifiers of the link. If the LSR doesn't 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 know the remote identifier of that link, the LSR should use a value
of 0 as the remote identifier. of 0 as the remote identifier.
6.2. Link Protection Type 4.2. Link Protection Type
The Link Protection Type represents the protection capability that The Link Protection Type represents the protection capability that
exists for a link. It is desirable to carry this information so 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 it may be used by the path computation algorithm to set up LSPs with
appropriate protection characteristics. This information is organized appropriate protection characteristics. This information is organized
in a hierarchy where typically the minimum acceptable protection is in a hierarchy where typically the minimum acceptable protection is
specified at path instantiation and a path selection technique is specified at path instantiation and a path selection technique is
used to find a path that satisfies at least the minimum acceptable used to find a path that satisfies at least the minimum acceptable
protection. Protection schemes are presented in order from lowest to protection. Protection schemes are presented in order from lowest to
highest protection. highest protection.
skipping to change at page 7, line 6 skipping to change at page 7, line 6
Enhanced Enhanced
If the link is of type Enhanced, it means that a protection scheme 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- that is more reliable than Dedicated 1+1, e.g., 4 fiber BLSR/MS-
SPRING, is being used to protect this link. SPRING, is being used to protect this link.
The Link Protection Type is optional, and if a Link State The Link Protection Type is optional, and if a Link State
Advertisement doesn't carry this information, then the Link Advertisement doesn't carry this information, then the Link
Protection Type is unknown. Protection Type is unknown.
6.3. Shared Risk Link Group Information 4.3. Shared Risk Link Group Information
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 SRLG. A link may belong to multiple SRLGs. Thus the SRLG
Information describes a list of SRLGs that the link belongs to. An 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 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 domain. The SRLG Information is an unordered list of SRLGs that the
link belongs to. link belongs to.
skipping to change at page 7, line 33 skipping to change at page 7, line 33
so that they do not have any links in common, and such that the path so that they do not have any links in common, and such that the path
SRLGs are disjoint. SRLGs are disjoint.
The SRLG Information may start with a configured value, in which case The SRLG Information may start with a configured value, in which case
it does not change over time, unless reconfigured. it does not change over time, unless reconfigured.
The SRLG Information is optional and if a Link State Advertisement The SRLG Information is optional and if a Link State Advertisement
doesn't carry the SRLG Information, then it means that SRLG of that doesn't carry the SRLG Information, then it means that SRLG of that
link is unknown. link is unknown.
6.4. Interface Switching Capability Descriptor 4.4. Interface Switching Capability Descriptor
In the context of this document we say that a link is connected to a 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 node by an interface. In the context of GMPLS interfaces may have
different switching capabilities. For example an interface that different switching capabilities. For example an interface that
connects a given link to a node may not be able to switch individual 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. 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 Interfaces at each end of a link need not have the same switching
capabilities. Interfaces on the same node need not have the same capabilities. Interfaces on the same node need not have the same
switching capabilities. switching capabilities.
skipping to change at page 9, line 10 skipping to change at page 9, line 9
An interface may have more than one Interface Switching Capability An interface may have more than one Interface Switching Capability
Descriptor. This is used to handle interfaces that support multiple Descriptor. This is used to handle interfaces that support multiple
switching capabilities, for interfaces that have Max LSP Bandwidth switching capabilities, for interfaces that have Max LSP Bandwidth
values that differ by priority level, and for interfaces that support values that differ by priority level, and for interfaces that support
discrete bandwidths. discrete bandwidths.
Depending on a particular Interface Switching Capability, the Depending on a particular Interface Switching Capability, the
Interface Switching Capability Descriptor may include additional Interface Switching Capability Descriptor may include additional
information, as specified below. information, as specified below.
6.4.1. Layer-2 Switch Capable 4.4.1. Layer-2 Switch Capable
If an interface is of type L2SC, it means that the node receiving If an interface is of type L2SC, it means that the node receiving
data over this interface can switch the received frames based on the data over this interface can switch the received frames based on the
layer 2 address. For example, an interface associated with a link layer 2 address. For example, an interface associated with a link
terminating on an ATM switch would be considered L2SC. terminating on an ATM switch would be considered L2SC.
6.4.2. Packet-Switch Capable 4.4.2. Packet-Switch Capable
If an interface is of type PSC-1 through PSC-4, it means that the If an interface is of type PSC-1 through PSC-4, it means that the
node receiving data over this interface can switch the received data node receiving data over this interface can switch the received data
on a packet-by-packet basis, based on the label carried in the "shim" on a packet-by-packet basis, based on the label carried in the "shim"
header [RFC3032]. The various levels of PSC establish a hierarchy of header [RFC3032]. The various levels of PSC establish a hierarchy of
LSPs tunneled within LSPs. LSPs tunneled within LSPs.
For Packet-Switch Capable interfaces the additional information For Packet-Switch Capable interfaces the additional information
includes Maximum LSP Bandwidth, Minimum LSP Bandwidth, and interface includes Maximum LSP Bandwidth, Minimum LSP Bandwidth, and interface
MTU. MTU.
skipping to change at page 10, line 20 skipping to change at page 10, line 15
On a PSC interface that supports Arbitrary SDH encoding, an LSP at On a PSC interface that supports Arbitrary SDH encoding, an LSP at
priority p could reserve any bandwidth between the Minimum LSP priority p could reserve any bandwidth between the Minimum LSP
Bandwidth and the Maximum LSP Bandwidth at priority p, provided that Bandwidth and the Maximum LSP Bandwidth at priority p, provided that
the bandwidth reserved by the LSP is a multiple of the Minimum LSP the bandwidth reserved by the LSP is a multiple of the Minimum LSP
Bandwidth. Bandwidth.
The Interface MTU is the maximum size of a packet that can be The Interface MTU is the maximum size of a packet that can be
transmitted on this interface without being fragmented. transmitted on this interface without being fragmented.
6.4.3. Time-Division Multiplex Capable 4.4.3. Time-Division Multiplex Capable
If an interface is of type TDM, it means that the node receiving data If an interface is of type TDM, it means that the node receiving data
over this interface can multiplex or demultiplex channels within an over this interface can multiplex or demultiplex channels within an
SDH payload. SDH payload.
For Time-Division Multiplex Capable interfaces the additional For Time-Division Multiplex Capable interfaces the additional
information includes Maximum LSP Bandwidth, the information on information includes Maximum LSP Bandwidth, the information on
whether the interface supports Standard or Arbitrary SDH, and Minimum whether the interface supports Standard or Arbitrary SDH, and Minimum
LSP Bandwidth. LSP Bandwidth.
skipping to change at page 11, line 17 skipping to change at page 11, line 12
the encoding of such information is outside the scope of this the encoding of such information is outside the scope of this
document. document.
A way to handle the case where an interface supports multiple A way to handle the case where an interface supports multiple
branches of the SDH multiplexing hierarchy, multiple Interface branches of the SDH multiplexing hierarchy, multiple Interface
Switching Capability Descriptors would be advertised, one per branch. Switching Capability Descriptors would be advertised, one per branch.
For example, if an interface supports VC-11 and VC-12 (which are not For example, if an interface supports VC-11 and VC-12 (which are not
part of same branch of SDH multiplexing tree), then it could part of same branch of SDH multiplexing tree), then it could
advertise two descriptors, one for each one. advertise two descriptors, one for each one.
6.4.4. Lambda-Switch Capable 4.4.4. Lambda-Switch Capable
If an interface is of type LSC, it means that the node receiving data If an interface is of type LSC, it means that the node receiving data
over this interface can recognize and switch individual lambdas over this interface can recognize and switch individual lambdas
within the interface. An interface that allows only one lambda per within the interface. An interface that allows only one lambda per
interface, and switches just that lambda is of type LSC. interface, and switches just that lambda is of type LSC.
The additional information includes Reservable Bandwidth per The additional information includes Reservable Bandwidth per
priority, which specifies the bandwidth of an LSP that could be priority, which specifies the bandwidth of an LSP that could be
supported by the interface at a given priority number. supported by the interface at a given priority number.
A way to handle the case of multiple data rates or multiple encodings A way to handle the case of multiple data rates or multiple encodings
within a single TE Link, multiple Interface Switching Capability within a single TE Link, multiple Interface Switching Capability
Descriptors would be advertised, one per supported data rate and Descriptors would be advertised, one per supported data rate and
encoding combination. For example, an LSC interface could support encoding combination. For example, an LSC interface could support
the establishment of LSC LSPs at both STM-16 and STM-64 data rates. the establishment of LSC LSPs at both STM-16 and STM-64 data rates.
6.4.5. Fiber-Switch Capable 4.4.5. Fiber-Switch Capable
If an interface is of type FSC, it means that the node receiving data If an interface is of type FSC, it means that the node receiving data
over this interface can switch the entire contents to another over this interface can switch the entire contents to another
interface (without distinguishing lambdas, channels or packets). interface (without distinguishing lambdas, channels or packets).
I.e., an interface of type FSC switches at the granularity of an I.e., an interface of type FSC switches at the granularity of an
entire interface, and can not extract individual lambdas within the entire interface, and can not extract individual lambdas within the
interface. An interface of type FSC can not restrict itself to just interface. An interface of type FSC can not restrict itself to just
one lambda. one lambda.
6.4.6. Multiple Switching Capabilities per interface 4.4.6. Multiple Switching Capabilities per interface
An interface that connects a link to an LSR may support not one, but An interface that connects a link to an LSR may support not one, but
several Interface Switching Capabilities. For example, consider a several Interface Switching Capabilities. For example, consider a
fiber link carrying a set of lambdas that terminates on an LSR fiber link carrying a set of lambdas that terminates on an LSR
interface that could either cross-connect one of these lambdas to interface that could either cross-connect one of these lambdas to
some other outgoing optical channel, or could terminate the lamdba, some other outgoing optical channel, or could terminate the lamdba,
and extract (demultiplex) data from that lambda using TDM, and then and extract (demultiplex) data from that lambda using TDM, and then
cross-connect these TDM channels to some outgoing TDM channels. To cross-connect these TDM channels to some outgoing TDM channels. To
support this a Link State Advertisement may carry a list of Interface support this a Link State Advertisement may carry a list of Interface
Switching Capabilities Descriptors. Switching Capabilities Descriptors.
6.4.7. Interface Switching Capabilities and Labels 4.4.7. Interface Switching Capabilities and Labels
Depicting a TE link as a tuple that contains Interface Switching Depicting a TE link as a tuple that contains Interface Switching
Capabilities at both ends of the link, some examples links may be: Capabilities at both ends of the link, some examples links may be:
[PSC, PSC] - a link between two packet LSRs [PSC, PSC] - a link between two packet LSRs
[TDM, TDM] - a link between two Digital Cross Connects [TDM, TDM] - a link between two Digital Cross Connects
[LSC, LSC] - a link between two OXCs [LSC, LSC] - a link between two OXCs
[PSC, TDM] - a link between a packet LSR and a Digital Cross Connect [PSC, TDM] - a link between a packet LSR and a Digital Cross Connect
[PSC, LSC] - a link between a packet LSR and an OXC [PSC, LSC] - a link between a packet LSR and an OXC
[TDM, LSC] - a link between a Digital Cross Connect and an OXC [TDM, LSC] - a link between a Digital Cross Connect and an OXC
skipping to change at page 12, line 38 skipping to change at page 12, line 33
[TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] [TDM, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
[LSC, LSC] - label represents a lambda [LSC, LSC] - label represents a lambda
[FSC, FSC] - label represents a port on an OXC [FSC, FSC] - label represents a port on an OXC
[PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH] [PSC, TDM] - label represents a TDM time slot [GMPLS-SONET-SDH]
[PSC, LSC] - label represents a lambda [PSC, LSC] - label represents a lambda
[PSC, FSC] - label represents a port [PSC, FSC] - label represents a port
[TDM, LSC] - label represents a lambda [TDM, LSC] - label represents a lambda
[TDM, FSC] - label represents a port [TDM, FSC] - label represents a port
[LSC, FSC] - label represents a port [LSC, FSC] - label represents a port
6.4.8. Other issues 4.4.8. Other issues
It is possible that Interface Switching Capability Descriptor will It is possible that Interface Switching Capability Descriptor will
change over time, reflecting the allocation/deallocation of LSPs. change over time, reflecting the allocation/deallocation of LSPs.
For example, assume that VC-3, VC-4, VC-4-4c, VC-4-16c and VC-4-64c For example, assume that VC-3, VC-4, VC-4-4c, VC-4-16c and VC-4-64c
LSPs can be established on a STM-64 interface whose Encoding Type is LSPs can be established on a STM-64 interface whose Encoding Type is
SDH. Thus, initially in the Interface Switching Capability Descriptor SDH. Thus, initially in the Interface Switching Capability Descriptor
the Minimum LSP Bandwidth is set to VC-3, and Maximum LSP Bandwidth the Minimum LSP Bandwidth is set to VC-3, and Maximum LSP Bandwidth
is set to STM-64 for all priorities. As soon as an LSP of VC-3 size is set to STM-64 for all priorities. As soon as an LSP of VC-3 size
at priority 1 is established on the interface, it is no longer at priority 1 is established on the interface, it is no longer
capable of VC-4-64c for all but LSPs at priority 0. Therefore, the capable of VC-4-64c for all but LSPs at priority 0. Therefore, the
skipping to change at page 13, line 15 skipping to change at page 13, line 7
indicating that the Maximum LSP Bandwidth is no longer STM-64, but indicating that the Maximum LSP Bandwidth is no longer STM-64, but
STM-16 for all but priority 0 (at priority 0 the Maximum LSP STM-16 for all but priority 0 (at priority 0 the Maximum LSP
Bandwidth is still STM-64). If subsequently there is another VC-3 Bandwidth is still STM-64). If subsequently there is another VC-3
LSP, there is no change in the Interface Switching Capability LSP, there is no change in the Interface Switching Capability
Descriptor. The Descriptor remains the same until the node can no Descriptor. The Descriptor remains the same until the node can no
longer establish a VC-4-16c LSP over the interface (which means that longer establish a VC-4-16c LSP over the interface (which means that
at this point more than 144 time slots are taken by LSPs on the at this point more than 144 time slots are taken by LSPs on the
interface). Once this happened, the Descriptor is modified again, interface). Once this happened, the Descriptor is modified again,
and the modified Descriptor is advertised to other nodes. and the modified Descriptor is advertised to other nodes.
6.5. Bandwidth Encoding 4.5. Bandwidth Encoding
Encoding in IEEE floating point format of the discrete values that Encoding in IEEE floating point format of the discrete values that
could be used to identify Unreserved bandwidth, Maximum LSP bandwidth could be used to identify Unreserved bandwidth, Maximum LSP bandwidth
and Minimum LSP bandwidth is described in Section 3.1.2 of [GMPLS- and Minimum LSP bandwidth is described in Section 3.1.2 of [GMPLS-
SIG]. SIG].
7. Examples of Interface Switching Capability Descriptor 5. Examples of Interface Switching Capability Descriptor
7.1. STM-16 POS Interface on a LSR 5.1. STM-16 POS Interface on a LSR
Interface Switching Capability Descriptor: Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1 Interface Switching Capability = PSC-1
Encoding = SDH Encoding = SDH
Max LSP Bandwidth[p] = 2.5 Gbps, for all p Max LSP Bandwidth[p] = 2.5 Gbps, for all p
If multiple links with such interfaces at both ends were to be If multiple links with such interfaces at both ends were to be
advertised as one TE link, link bundling techniques should be used. advertised as one TE link, link bundling techniques should be used.
7.2. GigE Packet Interface on a LSR 5.2. GigE Packet Interface on a LSR
Interface Switching Capability Descriptor: Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1 Interface Switching Capability = PSC-1
Encoding = Ethernet 802.3 Encoding = Ethernet 802.3
Max LSP Bandwidth[p] = 1.0 Gbps, for all p Max LSP Bandwidth[p] = 1.0 Gbps, for all p
If multiple links with such interfaces at both ends were to be If multiple links with such interfaces at both ends were to be
advertised as one TE link, link bundling techniques should be used. advertised as one TE link, link bundling techniques should be used.
7.3. STM-64 SDH Interface on a Digital Cross Connect with Standard SDH 5.3. STM-64 SDH Interface on a Digital Cross Connect with Standard SDH
Consider a branch of SDH multiplexing tree : VC-3, VC-4, VC-4-4c, Consider a branch of SDH multiplexing tree : VC-3, VC-4, VC-4-4c,
VC-4-16c, VC-4-64c. If it is possible to establish all these VC-4-16c, VC-4-64c. If it is possible to establish all these
connections on a STM-64 interface, the Interface Switching Capability connections on a STM-64 interface, the Interface Switching Capability
Descriptor of that interface can be advertised as follows: Descriptor of that interface can be advertised as follows:
Interface Switching Capability Descriptor: Interface Switching Capability Descriptor:
Interface Switching Capability = TDM [Standard SDH] Interface Switching Capability = TDM [Standard SDH]
Encoding = SDH Encoding = SDH
Min LSP Bandwidth = VC-3 Min LSP Bandwidth = VC-3
skipping to change at page 14, line 17 skipping to change at page 14, line 4
Consider a branch of SDH multiplexing tree : VC-3, VC-4, VC-4-4c, Consider a branch of SDH multiplexing tree : VC-3, VC-4, VC-4-4c,
VC-4-16c, VC-4-64c. If it is possible to establish all these VC-4-16c, VC-4-64c. If it is possible to establish all these
connections on a STM-64 interface, the Interface Switching Capability connections on a STM-64 interface, the Interface Switching Capability
Descriptor of that interface can be advertised as follows: Descriptor of that interface can be advertised as follows:
Interface Switching Capability Descriptor: Interface Switching Capability Descriptor:
Interface Switching Capability = TDM [Standard SDH] Interface Switching Capability = TDM [Standard SDH]
Encoding = SDH Encoding = SDH
Min LSP Bandwidth = VC-3 Min LSP Bandwidth = VC-3
Max LSP Bandwidth[p] = STM-64, for all p Max LSP Bandwidth[p] = STM-64, for all p
If multiple links with such interfaces at both ends were to be If multiple links with such interfaces at both ends were to be
advertised as one TE link, link bundling techniques should be used. advertised as one TE link, link bundling techniques should be used.
7.4. STM-64 SDH Interface on a Digital Cross Connect with two types of 5.4. STM-64 SDH Interface on a Digital Cross Connect with two types of
SDH multiplexing hierarchy supported SDH multiplexing hierarchy supported
Interface Switching Capability Descriptor 1: Interface Switching Capability Descriptor 1:
Interface Switching Capability = TDM [Standard SDH] Interface Switching Capability = TDM [Standard SDH]
Encoding = SDH Encoding = SDH
Min LSP Bandwidth = VC-3 Min LSP Bandwidth = VC-3
Max LSP Bandwidth[p] = STM-64, for all p Max LSP Bandwidth[p] = STM-64, for all p
Interface Switching Capability Descriptor 2: Interface Switching Capability Descriptor 2:
Interface Switching Capability = TDM [Arbitrary SDH] Interface Switching Capability = TDM [Arbitrary SDH]
Encoding = SDH Encoding = SDH
Min LSP Bandwidth = VC-4 Min LSP Bandwidth = VC-4
Max LSP Bandwidth[p] = STM-64, for all p Max LSP Bandwidth[p] = STM-64, for all p
If multiple links with such interfaces at both ends were to be If multiple links with such interfaces at both ends were to be
advertised as one TE link, link bundling techniques should be used. advertised as one TE link, link bundling techniques should be used.
7.5. Interface on an opaque OXC (SDH framed) with support for one lambda 5.5. Interface on an opaque OXC (SDH framed) with support for one lambda
per port/interface per port/interface
An "opaque OXC" is considered operationally an OXC, as the whole An "opaque OXC" is considered operationally an OXC, as the whole
lambda (carrying the SDH line) is switched transparently without lambda (carrying the SDH line) is switched transparently without
further multiplexing/demultiplexing, and either none of the SDH further multiplexing/demultiplexing, and either none of the SDH
overhead bytes, or at least the important ones are not changed. overhead bytes, or at least the important ones are not changed.
An interface on an opaque OXC handles a single wavelength, and An interface on an opaque OXC handles a single wavelength, and
cannot switch multiple wavelengths as a whole. Thus, an interface on cannot switch multiple wavelengths as a whole. Thus, an interface on
an opaque OXC is always LSC, and not FSC, irrespective of whether an opaque OXC is always LSC, and not FSC, irrespective of whether
skipping to change at page 15, line 22 skipping to change at page 15, line 6
[GMPLS-SIG]). [GMPLS-SIG]).
The following is an example of an interface switching capability The following is an example of an interface switching capability
descriptor on an SDH framed opaque OXC: descriptor on an SDH framed opaque OXC:
Interface Switching Capability Descriptor: Interface Switching Capability Descriptor:
Interface Switching Capability = LSC Interface Switching Capability = LSC
Encoding = SDH Encoding = SDH
Reservable Bandwidth = Determined by SDH Framer (say STM-64) Reservable Bandwidth = Determined by SDH Framer (say STM-64)
7.6. Interface on a transparent OXC (PXC) with external DWDM that 5.6. Interface on a transparent OXC (PXC) with external DWDM that
understands SDH framing understands SDH framing
This example assumes that DWDM and PXC are connected in such a way This example assumes that DWDM and PXC are connected in such a way
that each interface (port) on the PXC handles just a single that each interface (port) on the PXC handles just a single
wavelength. Thus, even if in principle an interface on the PXC could wavelength. Thus, even if in principle an interface on the PXC could
switch multiple wavelengths as a whole, in this particular case an switch multiple wavelengths as a whole, in this particular case an
interface on the PXC is considered LSC, and not FSC. interface on the PXC is considered LSC, and not FSC.
_______ _______
| | | |
skipping to change at page 16, line 10 skipping to change at page 15, line 39
The following is an example of an interface switching capability The following is an example of an interface switching capability
descriptor on a transparent OXC (PXC) with external DWDM that descriptor on a transparent OXC (PXC) with external DWDM that
understands SDH framing: understands SDH framing:
Interface Switching Capability Descriptor: Interface Switching Capability Descriptor:
Interface Switching Capability = LSC Interface Switching Capability = LSC
Encoding = SDH (comes from DWDM) Encoding = SDH (comes from DWDM)
Reservable Bandwidth = Determined by DWDM (say STM-64) Reservable Bandwidth = Determined by DWDM (say STM-64)
7.7. Interface on a transparent OXC (PXC) with external DWDM that is 5.7. Interface on a transparent OXC (PXC) with external DWDM that is
transparent to bit-rate and framing transparent to bit-rate and framing
This example assumes that DWDM and PXC are connected in such a way This example assumes that DWDM and PXC are connected in such a way
that each interface (port) on the PXC handles just a single that each interface (port) on the PXC handles just a single
wavelength. Thus, even if in principle an interface on the PXC could wavelength. Thus, even if in principle an interface on the PXC could
switch multiple wavelengths as a whole, in this particular case an switch multiple wavelengths as a whole, in this particular case an
interface on the PXC is considered LSC, and not FSC. interface on the PXC is considered LSC, and not FSC.
A TE link is a group of one or more interfaces on the PXC. All
interfaces on a given PXC are required to have identifiers unique to
_______ _______
| | | |
/|___| | /|___| |
| |___| PXC | | |___| PXC |
========| |___| | ========| |___| |
| |___| | | |___| |
\| |_______| \| |_______|
DWDM DWDM
(transparent to bit-rate and framing) (transparent to bit-rate and framing)
A TE link is a group of one or more interfaces on the PXC. All
interfaces on a given PXC are required to have identifiers unique to
that PXC, and these identifiers are used as labels (see 3.2.1.1 of that PXC, and these identifiers are used as labels (see 3.2.1.1 of
[GMPLS-SIG]). [GMPLS-SIG]).
The following is an example of an interface switching capability The following is an example of an interface switching capability
descriptor on a transparent OXC (PXC) with external DWDM that is descriptor on a transparent OXC (PXC) with external DWDM that is
transparent to bit-rate and framing: transparent to bit-rate and framing:
Interface Switching Capability Descriptor: Interface Switching Capability Descriptor:
Interface Switching Capability = LSC Interface Switching Capability = LSC
Encoding = Lambda (photonic) Encoding = Lambda (photonic)
Reservable Bandwidth = Determined by optical technology limits Reservable Bandwidth = Determined by optical technology limits
7.8. Interface on a PXC with no external DWDM 5.8. Interface on a PXC with no external DWDM
The absence of DWDM in between two PXCs, implies that an interface is The absence of DWDM in between two PXCs, implies that an interface is
not limited to one wavelength. Thus, the interface is advertised as not limited to one wavelength. Thus, the interface is advertised as
FSC. FSC.
A TE link is a group of one or more interfaces on the PXC. All A TE link is a group of one or more interfaces on the PXC. All
interfaces on a given PXC are required to have identifiers unique to interfaces on a given PXC are required to have identifiers unique to
that PXC, and these identifiers are used as port labels (see 3.2.1.1 that PXC, and these identifiers are used as port labels (see 3.2.1.1
of [GMPLS-SIG]). of [GMPLS-SIG]).
Interface Switching Capability Descriptor: Interface Switching Capability Descriptor:
Interface Switching Capability = FSC Interface Switching Capability = FSC
Encoding = Lambda (photonic) Encoding = Lambda (photonic)
Reservable Bandwidth = Determined by optical technology limits Reservable Bandwidth = Determined by optical technology limits
Note that this example assumes that the PXC does not restrict each Note that this example assumes that the PXC does not restrict each
port to carry only one wavelength. port to carry only one wavelength.
7.9. Interface on a OXC with internal DWDM that understands SDH framing 5.9. Interface on a OXC with internal DWDM that understands SDH framing
This example assumes that DWDM and OXC are connected in such a way This example assumes that DWDM and OXC are connected in such a way
that each interface on the OXC handles multiple wavelengths that each interface on the OXC handles multiple wavelengths
individually. In this case an interface on the OXC is considered LSC, individually. In this case an interface on the OXC is considered LSC,
and not FSC. and not FSC.
_______ _______
| | | |
/|| ||\ /|| ||\
| || OXC || | | || OXC || |
skipping to change at page 18, line 5 skipping to change at page 17, line 33
Interface Switching Capability Descriptor: Interface Switching Capability Descriptor:
Interface Switching Capability = LSC Interface Switching Capability = LSC
Encoding = SDH (comes from DWDM) Encoding = SDH (comes from DWDM)
Max LSP Bandwidth = Determined by DWDM (say STM-16) Max LSP Bandwidth = Determined by DWDM (say STM-16)
Interface Switching Capability = LSC Interface Switching Capability = LSC
Encoding = SDH (comes from DWDM) Encoding = SDH (comes from DWDM)
Max LSP Bandwidth = Determined by DWDM (say STM-64) Max LSP Bandwidth = Determined by DWDM (say STM-64)
7.10. Interface on a OXC with internal DWDM that is transparent to bit- 5.10. Interface on a OXC with internal DWDM that is transparent to bit-
rate and framing rate and framing
This example assumes that DWDM and OXC are connected in such a way This example assumes that DWDM and OXC are connected in such a way
that each interface on the OXC handles multiple wavelengths that each interface on the OXC handles multiple wavelengths
individually. In this case an interface on the OXC is considered LSC, individually. In this case an interface on the OXC is considered LSC,
and not FSC. and not FSC.
_______ _______
| | | |
/|| ||\ /|| ||\
skipping to change at page 18, line 37 skipping to change at page 18, line 16
The following is an example of an interface switching capability The following is an example of an interface switching capability
descriptor on an OXC with internal DWDM that is transparent to bit- descriptor on an OXC with internal DWDM that is transparent to bit-
rate and framing: rate and framing:
Interface Switching Capability Descriptor: Interface Switching Capability Descriptor:
Interface Switching Capability = LSC Interface Switching Capability = LSC
Encoding = Lambda (photonic) Encoding = Lambda (photonic)
Max LSP Bandwidth = Determined by optical technology limits Max LSP Bandwidth = Determined by optical technology limits
8. Example of interfaces that support multiple switching capabilities 6. Example of interfaces that support multiple switching capabilities
There can be many combinations possible, some are described below. There can be many combinations possible, some are described below.
8.1. Interface on a PXC+TDM device with external DWDM 6.1. Interface on a PXC+TDM device with external DWDM
As discussed earlier, the presence of the external DWDM limits that As discussed earlier, the presence of the external DWDM limits that
only one wavelength be on a port of the PXC. On such a port, the only one wavelength be on a port of the PXC. On such a port, the
attached PXC+TDM device can do one of the following. The wavelength attached PXC+TDM device can do one of the following. The wavelength
may be cross-connected by the PXC element to other out-bound optical may be cross-connected by the PXC element to other out-bound optical
channel, or the wavelength may be terminated as an SDH interface and channel, or the wavelength may be terminated as an SDH interface and
SDH channels switched. SDH channels switched.
From a GMPLS perspective the PXC+TDM functionality is treated as a From a GMPLS perspective the PXC+TDM functionality is treated as a
single interface. The interface is described using two Interface single interface. The interface is described using two Interface
skipping to change at page 19, line 21 skipping to change at page 19, line 5
Reservable Bandwidth = STM-64 Reservable Bandwidth = STM-64
and and
Interface Switching Capability Descriptor: Interface Switching Capability Descriptor:
Interface Switching Capability = TDM [Standard SDH] Interface Switching Capability = TDM [Standard SDH]
Encoding = SDH Encoding = SDH
Min LSP Bandwidth = VC-3 Min LSP Bandwidth = VC-3
Max LSP Bandwidth[p] = STM-64, for all p Max LSP Bandwidth[p] = STM-64, for all p
8.2. Interface on an opaque OXC+TDM device with external DWDM 6.2. Interface on an opaque OXC+TDM device with external DWDM
An interface on an "opaque OXC+TDM" device would also be advertised An interface on an "opaque OXC+TDM" device would also be advertised
as LSC+TDM much the same way as the previous case. as LSC+TDM much the same way as the previous case.
8.3. Interface on a PXC+LSR device with external DWDM 6.3. Interface on a PXC+LSR device with external DWDM
As discussed earlier, the presence of the external DWDM limits that As discussed earlier, the presence of the external DWDM limits that
only one wavelength be on a port of the PXC. On such a port, the only one wavelength be on a port of the PXC. On such a port, the
attached PXC+LSR device can do one of the following. The wavelength attached PXC+LSR device can do one of the following. The wavelength
may be cross-connected by the PXC element to other out-bound optical may be cross-connected by the PXC element to other out-bound optical
channel, or the wavelength may be terminated as a Packet interface channel, or the wavelength may be terminated as a Packet interface
and packets switched. and packets switched.
From a GMPLS perspective the PXC+LSR functionality is treated as a From a GMPLS perspective the PXC+LSR functionality is treated as a
single interface. The interface is described using two Interface single interface. The interface is described using two Interface
skipping to change at page 20, line 6 skipping to change at page 19, line 36
Encoding = SDH (comes from WDM) Encoding = SDH (comes from WDM)
Reservable Bandwidth = STM-64 Reservable Bandwidth = STM-64
and and
Interface Switching Capability Descriptor: Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1 Interface Switching Capability = PSC-1
Encoding = SDH Encoding = SDH
Max LSP Bandwidth[p] = 10 Gbps, for all p Max LSP Bandwidth[p] = 10 Gbps, for all p
8.4. Interface on a TDM+LSR device 6.4. Interface on a TDM+LSR device
On a TDM+LSR device that offers a channelized SDH interface the On a TDM+LSR device that offers a channelized SDH interface the
following may be possible: following may be possible:
- A subset of the SDH channels may be uncommitted. That is, they - A subset of the SDH channels may be uncommitted. That is, they
are not currently in use and hence are available for allocation. are not currently in use and hence are available for allocation.
- A second subset of channels may already be committed for transit - A second subset of channels may already be committed for transit
purposes. That is, they are already cross-connected by the SDH purposes. That is, they are already cross-connected by the SDH
cross connect function to other out-bound channels and thus are cross connect function to other out-bound channels and thus are
skipping to change at page 21, line 5 skipping to change at page 20, line 23
Min LSP Bandwidth = VC-3 Min LSP Bandwidth = VC-3
Max LSP Bandwidth[p] = STM-64, for all p Max LSP Bandwidth[p] = STM-64, for all p
and and
Interface Switching Capability Descriptor: Interface Switching Capability Descriptor:
Interface Switching Capability = PSC-1 Interface Switching Capability = PSC-1
Encoding = SDH Encoding = SDH
Max LSP Bandwidth[p] = 10 Gbps, for all p Max LSP Bandwidth[p] = 10 Gbps, for all p
9. Security Considerations 7. Normative References
The routing extensions proposed in this document do not raise any new [GMPLS-OSPF] Kompella, K., and Rekhter, Y. (Editors), "OSPF
security concerns. Extensions in Support of Generalized MPLS", (work in progress)
10. Acknowledgements [GMPLS-SIG] Berger, L., and Ashwood-Smith, P. (Editors), "Generalized
MPLS - Signaling Functional Description", (work in progress)
The authors would like to thank Suresh Katukam, Jonathan Lang, Zhi- [GMPLS-SONET-SDH] Mannie, E., and Papadimitriou, D. (Editors), "GMPLS
Wei Lin, and Quaizar Vohra for their comments and contributions to Extensions for SONET and SDH Control", (work in progress)
the draft.
11. References [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
Bundling in MPLS Traffic Engineering", (work in progress)
[ISIS-TE] Smit, H., Li, T., "IS-IS Extensions for Traffic [LMP] Lang, J. (Editor), "Link Management Protocol (LMP)", (work in
Engineering", draft-ietf-isis-traffic-04.txt (work in progress) progress)
[LSP-HIER] Kompella, K., Rekhter, Y., "LSP Hierarchy with MPLS TE", [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS
draft-ietf-mpls-lsp-hierarchy-04.txt (work in progress) TE", (work in progress)
[GMPLS-SIG] Ashwood-Smith, P., et al., "Generalized MPLS - Signaling [OSPF-TE] Katz, D., Yeung, D., and Kompella, K., "Traffic Engineering
Functional Description", draft-ietf-mpls-generalized-signaling-07.txt Extensions to OSPF", (work in progress)
(work in progress)
[GMPLS-SONET-SDH] Mannie, E., "GMPLS Extensions for SONET and SDH [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Control", draft-ietf-ccamp-gmpls-sonet-sdh-03.txt (work in progress) Requirement Levels", BCP 14, RFC 2119, March 1997.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering [RFC3032] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 3032,
Extensions to OSPF", draft-katz-yeung-ospf-traffic-06.txt January 2001.
[GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS 8. Informative References
Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls-
extensions-10.txt (work in progress)
[GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF [GMPLS-ISIS] Kompella, K., Rekhter, Y. (Editors), "IS-IS Extensions
Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf- in Support of Generalized MPLS", (work in progress)
gmpls-extensions-06.txt (work in progress)
[LINK-BUNDLE] Kompella, K., Rekhter, Y., Berger, L., "Link Bundling [ISIS-TE] Smit, H., Li, T., "IS-IS Extensions for Traffic
in MPLS Traffic Engineering", draft-ietf-mpls-bundle-00.txt (work in Engineering", (work in progress)
progress)
[LMP] Lang, J., et al., "Link Management Protocol (LMP)", work in 9. Security Considerations
progress
12. Authors' Information The routing extensions proposed in this document do not raise any new
security concerns.
Kireeti Kompella 10. Acknowledgements
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
Email: kireeti@juniper.net
Yakov Rekhter The authors would like to thank Suresh Katukam, Jonathan Lang, Zhi-
Juniper Networks, Inc. Wei Lin, and Quaizar Vohra for their comments and contributions to
1194 N. Mathilda Ave the draft.
Sunnyvale, CA 94089
Email: yakov@juniper.net 11. Contributors
Ayan Banerjee Ayan Banerjee
Calient Networks Calient Networks
5853 Rue Ferrari 5853 Rue Ferrari
San Jose, CA 95138 San Jose, CA 95138
Phone: +1.408.972.3645 Phone: +1.408.972.3645
Email: abanerjee@calient.net Email: abanerjee@calient.net
John Drake John Drake
Calient Networks Calient Networks
skipping to change at page 23, line 13 skipping to change at page 22, line 9
Email: greg@ciena.com Email: greg@ciena.com
Don Fedyk Don Fedyk
Nortel Networks Corp. Nortel Networks Corp.
600 Technology Park Drive 600 Technology Park Drive
Billerica, MA 01821 Billerica, MA 01821
Phone: +1-978-288-4506 Phone: +1-978-288-4506
Email: dwfedyk@nortelnetworks.com Email: dwfedyk@nortelnetworks.com
Eric Mannie Eric Mannie
GTS Network Services Libre Exaministe
RDI Department, Core Network Technology Group Email: eric_mannie@hotmail.com
Terhulpsesteenweg, 6A
1560 Hoeilaart, Belgium
Phone: +32-2-658.56.52
Email: eric.mannie@ebone.com
Debanjan Saha Debanjan Saha
Tellium Optical Systems Tellium Optical Systems
2 Crescent Place 2 Crescent Place
P.O. Box 901 P.O. Box 901
Ocean Port, NJ 07757 Ocean Port, NJ 07757
Phone: (732) 923-4264 Phone: (732) 923-4264
Email: dsaha@tellium.com Email: dsaha@tellium.com
Vishal Sharma Vishal Sharma
skipping to change at line 1007 skipping to change at page 23, line 4
70 Abele Rd, Bldg 1200 70 Abele Rd, Bldg 1200
Bridgeville PA 15017 Bridgeville PA 15017
Email: dbasak@accelight.com Email: dbasak@accelight.com
Lou Berger Lou Berger
Movaz Networks, Inc. Movaz Networks, Inc.
7926 Jones Branch Drive 7926 Jones Branch Drive
Suite 615 Suite 615
McLean VA, 22102 McLean VA, 22102
Email: lberger@movaz.com Email: lberger@movaz.com
12. Authors' Information
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
Email: kireeti@juniper.net
Yakov Rekhter
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
Email: yakov@juniper.net
Intellectual Property Rights Notices
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
 End of changes. 

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