draft-ietf-ccamp-gmpls-routing-06.txt   draft-ietf-ccamp-gmpls-routing-07.txt 
Network Working Group K. Kompella (Editor) Network Working Group K. Kompella, Editor
Internet Draft Y. Rekhter (Editor) Internet Draft Y. Rekhter, Editor
Category: Standards Track Juniper Networks Category: Standards Track Juniper Networks
Expires: December 2003 June 2003 Expires: April 2004 October 2003
Routing Extensions in Support of Generalized MPLS Routing Extensions in Support of Generalized
Multi-Protocol Label Switching
draft-ietf-ccamp-gmpls-routing-06.txt draft-ietf-ccamp-gmpls-routing-07.txt
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.
skipping to change at page 3, line 5 skipping to change at page 2, line 34
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.
0.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.
Changes since the last version
Added text that this document only covers single layer networks.
Updated references.
Specification of Requirements Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1. Introduction 1. 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 (TE).
2. GMPLS TE Links 2. 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
skipping to change at page 5, line 40 skipping to change at page 5, line 33
there may be switches capable of only VC-11, VC-12, and VC-3, there may be switches capable of only VC-11, VC-12, and VC-3,
where as there may be others that can only support VC-3 and VC-4. where as there may be others that can only support VC-3 and VC-4.
Even though a network element cannot support a specific layer, it Even though a network element cannot support a specific layer, it
should be able to know if a network element elsewhere in the should be able to know if a network element elsewhere in the
network can support an adaptation that would enable that network can support an adaptation that would enable that
unsupported layer to be used. For example, a VC-11 switch could unsupported layer to be used. For example, a VC-11 switch could
use a VC-3 capable switch if it knew that a VC-11 path could be use a VC-3 capable switch if it knew that a VC-11 path could be
constructed over a VC-3 link connection. constructed over a VC-3 link connection.
From the factors presented above, development of layer specific GMPLS From the factors presented above, development of layer specific GMPLS
routing drafts should use the following principles for TE-link routing documents should use the following principles for TE-link
attributes. attributes.
1. Separation of attributes. The attributes in a given layer are 1. Separation of attributes. The attributes in a given layer are
separated from attributes in another layer. separated from attributes in another layer.
2. Support of inter-layer attributes (e.g., adaptation 2. Support of inter-layer attributes (e.g., adaptation
relationships). Between a client and server layer, a general relationships). Between a client and server layer, a general
mechanism for describing the layer relationship exists. For mechanism for describing the layer relationship exists. For
example "4 client links of type X can be supported by this server example "4 client links of type X can be supported by this server
layer link". Another example is being able to identify when two layer link". Another example is being able to identify when two
skipping to change at page 6, line 15 skipping to change at page 6, line 8
3. Support for inheritable attributes. Attributes which can be 3. Support for inheritable attributes. Attributes which can be
inherited should be identified. inherited should be identified.
4. Layer extensibilty. Attributes should be represented in routing 4. Layer extensibilty. Attributes should be represented in routing
such that future layers can be accommodated. This is much like such that future layers can be accommodated. This is much like
the notion of the generalized label. the notion of the generalized label.
5. Explicit attribute scope. For example, it should be clear whether 5. Explicit attribute scope. For example, it should be clear whether
a given attribute applies to a set of links at the same layer. a given attribute applies to a set of links at the same layer.
The present document captures general attributes that apply to a
single layer network, but doesn't capture inter-layer relationships
of attributes. This work is left to a future document.
2.2. Excluding data traffic from control channels 2.2. 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 6, line 40 skipping to change at page 6, line 37
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 [LSP_HIER]), R installs a discard route for destination capable (see [LSP_HIER]), R installs a discard route for destination
D. Otherwise, R installs (as usual) a route for destination D with 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- nexthop I. Note that R need only do this check if it has
switch incapable links; if all of its links are packet-switch packet-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.
In other instances it may be desirable to keep the whole address In other instances it may be desirable to keep the whole address
space of a GMPLS routing plane disjoint from the endpoint addresses space of a GMPLS routing plane disjoint from the endpoint addresses
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.
skipping to change at page 8, line 34 skipping to change at page 8, line 29
this link. this link.
Dedicated 1+1 Dedicated 1+1
If the link is of type Dedicated 1+1, it means that a dedicated If the link is of type Dedicated 1+1, it means that a dedicated
disjoint link is protecting this link. However, the protecting disjoint link is protecting this link. However, the protecting
link is not advertised in the link state database and is therefore link is not advertised in the link state database and is therefore
not available for the routing of LSPs. not available for the routing of LSPs.
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
SPRING, is being used to protect this link. BLSR/MS-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.
3.3. Shared Risk Link Group Information 3.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
skipping to change at page 14, line 49 skipping to change at page 14, line 38
Capability Descriptor. The Descriptor remains the same until the Capability Descriptor. The Descriptor remains the same until the
node can no longer establish a VC-4-16c LSP over the interface (which node can no 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 means that at this point more than 144 time slots are taken by LSPs
on the interface). Once this happened, the Descriptor is modified on the interface). Once this happened, the Descriptor is modified
again, and the modified Descriptor is advertised to other nodes. again, and the modified Descriptor is advertised to other nodes.
3.5. Bandwidth Encoding 3.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
SIG]. [GMPLS-SIG].
4. Examples of Interface Switching Capability Descriptor 4. Examples of Interface Switching Capability Descriptor
4.1. STM-16 POS Interface on a LSR 4.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
skipping to change at page 19, line 19 skipping to change at page 19, line 19
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)
4.10. Interface on a OXC with internal DWDM that is transparent to bit- 4.10. Interface on a OXC with internal DWDM that is transparent to
rate and framing bit-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 individually. In this case an interface on the OXC is considered
LSC, and not FSC. LSC, and not FSC.
_______ _______
| | | |
/|| ||\ /|| ||\
| || OXC || | | || OXC || |
skipping to change at page 19, line 43 skipping to change at page 19, line 43
\||_______||/ \||_______||/
DWDM DWDM
(transparent to bit-rate and framing) (transparent to bit-rate and framing)
A TE link is a group of one or more of the interfaces on the OXC. A TE link is a group of one or more of the interfaces on the OXC.
All lambdas associated with a particular interface are required to All lambdas associated with a particular interface are required to
have identifiers unique to that interface, and these identifiers are have identifiers unique to that interface, and these identifiers are
used as labels (see 3.2.1.1 of [GMPLS-SIG]). used as labels (see 3.2.1.1 of [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 OXC with internal DWDM that is transparent to bit- descriptor on an OXC with internal DWDM that is transparent to
rate and framing: 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)
Max LSP Bandwidth = Determined by optical technology limits Max LSP Bandwidth = Determined by optical technology limits
5. Example of interfaces that support multiple switching capabilities 5. 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.
skipping to change at page 22, line 10 skipping to change at page 22, line 10
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
6. Normative References 6. Normative References
[GMPLS-OSPF] Kompella, K., and Rekhter, Y. (Editors), "OSPF [GMPLS-OSPF] Kompella, K., and Rekhter, Y. (Editors), "OSPF
Extensions in Support of Generalized MPLS", (work in progress) Extensions in Support of Generalized MPLS", (work in progress)
[GMPLS-SIG] Berger, L., and Ashwood-Smith, P. (Editors), "Generalized [GMPLS-SIG] Berger, L. (Editor), "Generalized Multi-Protocol Label
MPLS - Signaling Functional Description", (work in progress) Switching (GMPLS) Signaling Functional Description", RFC 3471,
January 2003
[GMPLS-SONET-SDH] Mannie, E., and Papadimitriou, D. (Editors), "GMPLS [GMPLS-SONET-SDH] Mannie, E., and Papadimitriou, D. (Editors),
Extensions for SONET and SDH Control", (work in progress) "Generalized Multi-Protocol Label Switching Extensions for SONET
and SDH Control", [RFC Ed Queue]
[LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link [LINK-BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link
Bundling in MPLS Traffic Engineering", (work in progress) Bundling in MPLS Traffic Engineering", [RFC Ed Queue]
[LMP] Lang, J. (Editor), "Link Management Protocol (LMP)", (work in [LMP] Lang, J. (Editor), "Link Management Protocol (LMP)", (work in
progress) progress)
[LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with MPLS [LSP-HIER] Kompella, K., and Rekhter, Y., "LSP Hierarchy with
TE", (work in progress) Generalized MPLS TE", [RFC Ed Queue]
[OSPF-TE] Katz, D., Yeung, D., and Kompella, K., "Traffic Engineering [OSPF-TE] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering
Extensions to OSPF", (work in progress) (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3032] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 3032, [RFC3032] Rosen, E., et al, "MPLS Label Stack Encoding", RFC 3032,
January 2001. January 2001.
7. Informative References 7. Informative References
[GMPLS-ISIS] Kompella, K., Rekhter, Y. (Editors), "IS-IS Extensions [GMPLS-ISIS] Kompella, K., Rekhter, Y. (Editors), "IS-IS Extensions
skipping to change at page 23, line 12 skipping to change at page 23, line 12
[ISIS-TE] Smit, H., Li, T., "IS-IS Extensions for Traffic [ISIS-TE] Smit, H., Li, T., "IS-IS Extensions for Traffic
Engineering", (work in progress) Engineering", (work in progress)
8. Security Considerations 8. Security Considerations
The routing extensions proposed in this document do not raise any new The routing extensions proposed in this document do not raise any new
security concerns. security concerns.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Suresh Katukam, Jonathan Lang, Zhi- The authors would like to thank Suresh Katukam, Jonathan Lang,
Wei Lin, and Quaizar Vohra for their comments and contributions to Zhi-Wei Lin, and Quaizar Vohra for their comments and contributions
the draft. Thanks too to Stephen Shew for the text regarding to the document. Thanks too to Stephen Shew for the text regarding
"Representing TE Link Capabilities". "Representing TE Link Capabilities".
10. Contributors 10. 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
skipping to change at page 25, line 33 skipping to change at page 25, line 33
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
 End of changes. 

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