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