CCAMP Working Group E. Mannie (Ebone) Internet Draft G. Bernstein (Ciena) Expiration Date: January 2002 Bala Rajagopalan (Tellium) Mike Raftelis (WhiteRock) Document: draft-mannie-mpls-sdh- Dimitri Papadimitriou (Alcatel) ospf-isis-01.txt Suresh Katukam (Cisco) Vishal Sharma (Metanoia) (Editors) July 2001 Extensions to OSPF and IS-IS in support of MPLS for SDH/SONET Control draft-mannie-mpls-sdh-ospf-isis-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Abstract This document discusses and explains some of the extensions required in existing routing protocols to support the routing of dynamically established SDH/SONET circuits using the GMPLS architecture [2]. In particular, the document specifies the GMPLS routing extensions to OSPF and IS-IS routing protocols for SDH/SONET networks, which complement the specifications in [3],[4]. Table of Contents 1. Introduction.....................................................2 2. Specification of Requirements....................................5 3. Abbreviations....................................................5 Expires January 2002 [Page 1] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 4. Static Link Capabilities.........................................6 4.1. Link Multiplex Capability......................................6 4.1.1. Structure of SDH/SONET Multiplex Capabilities................6 4.1.2. Link SDH/SONET Multiplex Capability TLV (LS-MC)..............7 4.2. Link Concatenation Capability..................................9 4.2.1. Concatenation of SDH/SONET Signals...........................9 4.2.2. Link SDH/SONET Concatenation Capability TLV (LS-CC).........10 4.3. Link Bundling.................................................13 4.3.1. Bundling of SDH/SONET Signals...............................13 4.3.2. Link SDH/SONET Bundle Size TLV (LS-BS)......................13 4.4. Link Protection Capability....................................14 4.4.1. Enhancement to Link Protection to Account for SDH/SONET Rings14 4.4.2. Example.....................................................15 4.4.3. Modified Link Protection Type TLV...........................16 5. Dynamic Link Capabilities.......................................18 5.1. Overview of Bandwidth Status Reporting in SDH/SONET...........18 5.2. Link Capacity Allocation in SDH/SONET.........................19 5.2.1. Link SDH/SONET Allocation TLV (LS-A)........................20 5.3. Grouping of Contiguously Allocated Signals....................21 5.3.1. Link SDH/SONET Block Allocation TLV (LS-BA).................22 6. Interworking Capabilities.......................................23 6.1. Interconnection Capability....................................23 6.1.1. Router SDH Interconnection Capability TLV (RS-IC)...........23 6.2. Interworking Capability.......................................24 6.2.1. Router SDH-SONET Interworking Capability TLV (RS-SI)........25 6.2.2. Interworking between STM-1 and STS-1........................27 6.2.3. Interworking between STM-Mc and STS-Nc......................27 6.2.4. Interworking between STM-1 and STS-1 Lower Order Signals....28 6.3. Overhead Byte Differences between SDH and SONET...............28 7. Updating Routing Databases......................................28 8. Size of Routing Protocol PDUs...................................30 9. Security Considerations.........................................30 10. References.....................................................30 11. Acknowledgments................................................32 12. Author's Addresses.............................................32 1. Introduction A framework for MPLS-based control of SDH/SONET networks was presented in [5]. It provides an overview of the operation and management of SDH/SONET networks and discusses many of the routing and signaling issues that must be considered in the dynamic control of SDH/SONET transport networks. The current document is based on the TE extensions defined in [6] and [7]. It uses the notion of forwarding adjacencies defined in [8], and supports link bundling as defined in [9]. In addition, the Expires January 2002 [Page 2] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 document proposes support for some forms of SDH-SONET internetworking. The document proposes several new TLVs based on [6], [7], and [10], which complement those proposed in [3], [4]. Routing information is transported in OSPF using Link State Advertisements (LSAs) grouped in OSPF Packet Data Units (PDUs), and is transported in IS-IS in Link State PDUs (LSPs). An important observation is that to enable SDH/SONET routing, the routing protocol needs to transport two different sets (or types) of information. A static set that describes the capabilities of an SDH/SONET LSR and its SDH/SONET links, independently of their usage, and a dynamic set that describes (in some appropriate manner) the resources (or SDH/SONET signals) that are in use at each link. That is, the operational status of each link. For each of these sets, new TLVs are defined as follows. The TLVs describing the static capabilities of an SDH/SONET LSR and its links are: i) LS-MC TLV: Link SDH/SONET Multiplex Capability TLV. ii) LS-C TLV : Link SDH/SONET Concatenation TLV. iii) LS-BS TLV: Link SDH/SONET Bundle Size TLV. iv) LS-P TLV : Link SDH/SONET Protection TLV. v) RS-IC TLV: Router SDH Interconnection Capability TLV. vi) RS-SI TLV: Router SDH-SONET Interworking TLV. The TLVs describing the dynamic (or operational) status of an SDH/SONET link are: i) LS-A-TLV : Link SDH/SONET Allocation TLV. ii) LS-BA TLV: Link SDH/SONET Block Allocation TLV. A link between two adjacent LSRs is defined in [11] as one logical control channel (LCC) and one or more fibers with the same traffic engineering (TE) characteristics. If there is more than one fiber in a link, the bundling technique of [9] is applied. The OSPF and IS-IS TE routing extensions for optical switching given in [3] and [4] respectively, apply to all the fibers in that link. The fundamental idea behind bundling is that all components in a bundle must have exactly the same TE characteristics. If WDM is used for some fibers, we assume that each wavelength will act as a separate (virtual) fiber. The result is that each component of a bundle must have the same SDH/SONET multiplexing and concatenation capabilities as defined later in this draft. The two corresponding TLVs (LS-MC and LS-C) are specified once, but apply to each component. Thus, no per component information or identification is required for these TLVs. The Link SDH/SONET Bundle Size TLV defined later gives the total number of (identical) components in a bundle. Despite being bundled, the usage of each component in a bundle may differ completely, however, with individual component structured Expires January 2002 [Page 3] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 (i.e. channelized) very differently from one another. For example, in a bundled link comprised of two fibers, the first component (fiber) could be structured in STM-4s, while the second component could be structured in VC-3s. Likewise, each STM-i of an STM-N (N > 1) could also be structured differently from the others. A key observation, therefore, is that on a given bundled link it is not possible to simply represent the total number of signals that are allocated per bandwidth level. It is also essential to know their positions (where they are allocated) and their signal types. This is of fundamental importance, since an allocated signal in SDH/SONET does not only consume bandwidth at a given position in the SDH/SONET multiplex (see [5]), it also imposes some restrictions on the future allocations that can be made from the free portion of the SDH/SONET multiplex. For example, a smart routing algorithm may need to allocate some signals from a specific STM-i of a given link component to maintain enough free space to setup further higher order signals in another STM-j. Since, in general, one cannot make assumptions about the nature of the TE routing algorithms that different providers or vendors may use, we cannot restrict or simplify the information to be advertised in the routing protocols. In fact, during the lifetime of the network, bandwidth fragmentation ends up creating "holes" in the SDH/SONET multiplex. Thus, a routing algorithm need to know the location, type, and size of each of these "holes" in order to intelligently route new demands and keep the network operating efficiently. Note that even though a demand may be satisfied by the sum of the available "holes", it may still be infeasible to serve it in practice, because there may be no single "hole" capable of accommodating it. For instance, knowledge of the fact that 21 VC-12s are allocated on an STM-N link is not enough to indicate whether they are all allocated in the same VC-3 of a single STM-1, or whether they are split across different VC-3s of different STM-1s. Furthermore, "holes" cannot be filled with just any signal, even if there is sufficient bandwidth to accommodate that signal, since the rules of SDH/SONET multiplexing must be respected in any signal allocation. Therefore, signals allocated in a (bundled) link must be individually advertised. They may, however, be grouped together in a higher order signal advertisement when this higher order signal is completely filled. For instance, when a complete VC-3 is filled, it is better to advertise a single VC-3 rather than advertising each sub-signal independently. A label as defined in [12] identifies a signal and its position in a particular STM-N/STS-N multiplex. Note that a signaling protocol also needs to identify the fiber, or the fiber and the wavelength, corresponding to the STM-N. Similarly, if a link is bundled, the Expires January 2002 [Page 4] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 routing protocol will have to advertise the corresponding bundle component on which a signal is allocated. This creates the problem of having to potentially flood a huge amount of routing information. For instance, with a bundle of 10 fibers and 40 wavelengths per fiber at STM-64, there are potentially 76800 VC-3s that can be allocated on that bundled link, and that may therefore have to be advertised to all SDH-LSRs in the same routing domain. Even with an optimization such as a bitmap, this is potentially a huge amount of information to flood. The efficiency of an optimized representation depends on several factors, such as the number of contiguously allocated signals, the dynamics of the demands in terms of their duration and/or bandwidth, and so on. We propose a simple dual representation scheme of the allocated signals using a mandatory representation based on the labeling defined in [12] and an optional per block representation. Each one uses a different TLV in a separate LSA/LSP. The mandatory representation has the advantage of being compatible with the label representation for the signaling protocols. Other representations are for further study. Another way to cope with the large volume of routing information to be distributed may be simply to limit the size of a routing domain in SDH/SONET, e.g., by using smaller IGP areas. 2. 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. 3. Abbreviations ADM Add-Drop Multiplexer AU-n Administrative Unit-n (SDH) AUG Administrative Unit Group (SDH) DCC Data Communication Channel LSA Link State Advertisement LSP Label Switched Path (MPLS terminology) LSP Link State PDU (IS-IS terminology) MPLS Multi-Protocol Label Switching POH Path Overhead RSOH Regenerator Section Overhead SDH Synchronous Digital Hierarchy SOH Section Overhead STM(-N) Synchronous Transport Module (-N) STS(-N) Synchronous Transport Signal-Level N (SONET) TU-n Tributary Unit-n (SDH) TUG(-n) Tributary Unit Group (-n) (SDH) Expires January 2002 [Page 5] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 VC-n Virtual Container-n (SDH) VTn Virtual Tributary-n (SONET) 4. Static Link Capabilities We first review the static capabilities of an SDH/SONET link that must be advertised in the routing protocols. There are four basic static link properties to be advertised: the multiplexing capability of the link, the concatenation capability of the link, the manner in which the link is bundled (if at all), and the protection capabilities of the link. In the following sections, we discuss each of these separately. 4.1. Link Multiplex Capability The types of signals that are supported by an end system (switch, multiplexer, or terminal) are an important piece of network capability information that should be distributed via a routing protocol. Thus, the purpose of the link multiplex capability is to succinctly describe the types of signals that can be switched by a node on one end of a link (rather than the signal type actually carried on the link). For example, depending on how it is channelized, an OC-48 link may contain a variety of signals. From a routing and path computation perspective, however, we are interested in knowing exactly which of these signals can be switched at a particular end of that link. 4.1.1. Structure of SDH/SONET Multiplex Capabilities The framework for MPLS-based control of SDH/SONET [5] describes the basic SDH and SONET signals together with their corresponding super rate signals, STS-Mc and STS-Nc, respectively. Since the GMPLS-based control of transport networks is being considered to control multiplexing at an even finer level of granularity, we briefly review the structure of an STM-1 and an STS-1 signal. In the case of SDH, the STM-1 frame may contain either one VC-4 or three multiplexed VC-3s. In case of SONET, the smallest granularity signal that we will be dealing with within a SONET STS-1 frame is known as a Virtual Tributary (VT). Virtual Tributaries come in four sizes VT1.5 (1.728 Mbps), VT2 (2.304 Mbps), VT3 (2.304 Mbps), and VT6 (6.912 Mbps). VT1.5 and VT2 are used for transporting the ever popular DS1 (T1) and E1 signals. Some of these have equivalents in SDH, i.e., VT1.5 (TU-11), VT2 (TU-12) and VT6 (TU-2). There is no SDH equivalent for a VT3. In addition to their payload carrying capabilities, the VTs include overhead for functions such as: path signal label (via the C2 byte, which identifies the payload type), VT level fault management, Expires January 2002 [Page 6] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 performance monitoring, and signal identification (via the VT path trace, or J2, byte). These signals are not simply placed within the STS-1 payload envelope, but are first grouped within VT Groups. Seven VT Groups are contained within an STS-1 signal (and they all have the same size). A VT Group must contain only one type of VT. A VT group can contain up to four VT1.5s, or three VT2s, or two VT3s, or one VT6. Hence once a VT group is committed to holding one type of VT, it is committed to only holding that type of VT until all VTs within the group are removed. In SDH, VT groups are known as tributary unit group level 2 (TUG-2). The types of signals, i.e., VT types, that are supported by an end system is critical information regarding the capability of the network that must be distributed via a routing protocol. Analogously, being able to identify which VT we are referring to is important signal information that must be distributed via the label distribution/signaling protocol. The GMPLS signaling extensions for SDH/SONET [12] provide a self- describing numbering scheme to identify a particular SDH/SONET signal within the SDH/SONET multiplex. These are based on an extension of the (K, L, M) encoding defined in [13]. 4.1.2. Link SDH/SONET Multiplex Capability TLV (LS-MC) The Link SDH/SONET Multiplex Capability TLV describes the SDH STM-1 or the SONET STS-1 multiplexing structure available on a link. It indicates precisely the signals that can be allocated in an STM- 1/STS-1 multiplex, not the actual allocation. The signals actually allocated on a link are advertised using the LS-A or LS-BA TLVs. Signal concatenation is advertised via the Link SDH/SONET Concatenation TLV. The Link SDH/SONET Multiplex Capability TLV describes the multiplex capabilities of a single STM-1/STS-1. If a link is an STM-M/STS-N, M,N > 1, it is assumed that all STM-1/STS-1 components of that STM- M/STS-N have the same multiplexing capabilities. The types and sizes of signals that can be carried within an STM- 1/STS-1 and that are supported by an SDH/SONET LSR are an important capability that is needed during path computation. A node that is computing a path considers the Link Descriptor subˇTLV (see [3], [4]) and the LS-MC sub TLV of a link to ensure that the link (a) has the capability to carry/switch the signal and (b) that it has sufficient available bandwidth (that is, space at the appropriate place within the SDH/SONET multiplex) to carry the signal. In IS-IS, this TLV is a sub-TLV of the Extended IS Reachability TLV with type TBD. In OSPF, this TLV is a sub-TLV of the Link TLV, with type TBD. The length of this TLV is one octet. The value is coded in 8 bits, and is defined as a vector of flags. Expires January 2002 [Page 7] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MC Flag | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OSPF Link SDH/SONET Multiplex Capability TLV. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 1 | MC Flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IS-IS Link SDH/SONET Multiplex Capability TLV. The MC Flag above indicates the capability of a link to multiplex a given signal into the higher order signal directly above it in the SDH/SONET multiplex tree (see [5]). The flag is actually a vector of bits. A bit value of 1 indicates that the multiplexing capability is supported while a bit value of 0 indicates that the multiplexing capability is not supported. Bit 1 is the highest order bit of the flag field. The MC-Flag for SDH is: - Bit 1 : TUG-3 in VC-4. - Bit 2 : TU-3 in TUG-3. - Bit 3 : AU-3s in AUG. - Bit 4 : TUG-2s in TUG-3. - Bit 5 : TUG-2s in VC-3. - Bit 6 : TU-2 in TUG-2. - Bit 7 : TU-12s in TUG-2. - Bit 8 : TU-11s in TUG-2. For instance, a value of: - "11111111" (0xff) indicates a full SDH multiplexing capability, - "11100000" indicates that the lowest multiplexing capability is VC-3, - "00001111" (0x0f) indicates a full STM-0 multiplexing capability, - "10010010" indicates that only VC-12 can be multiplexed. A binary value of "00000000" should not be advertised since it indicates no SDH capability at all. Note that some values are prohibited, since a lower order multiplexing must always be contained in a higher order multiplexing. For instance, the binary value "00011111" does not make sense. Similarly, the MC Flag for SONET is: Expires January 2002 [Page 8] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 - Bit 1 : VT-1.5 - Bit 2 : VT-2 - Bit 3 : VT-6 - Bit 4 : reserved - Bit 5 : reserved - Bit 6 : reserved - Bit 7 : reserved (VT-3 has not been assigned a bit value, since it is not a commonly supported signal type.) 4.2. Link Concatenation Capability 4.2.1. Concatenation of SDH/SONET Signals (A) Concatenation of SDH Signals SDH defines two types of concatenation: - contiguous concatenation; - virtual concatenation. The first is the concatenation of contiguous signals in the multiplex, and the second is the concatenation of signals that are not contiguous. Also, concatenation of SDH signals is only defined for AU-4s and TU-2s. The virtual concatenation of AU-4s is FFS in [13]. Both types of concatenation are defined for TU-2s. TU-2s may be either concatenated contiguously in a higher order VC-3, or virtually in a higher order VC-4. (B) Concatenation of SONET Signals Reference [14] discusses the importance of virtual concatenation of both higher order (super rate) SONET signals and lower order SONET signals. Whether or not some of the lower order concatenation capabilities are offered as a network service, there is a strong push for edge devices to offer this capability. Hence, it is important to advertise SONET low order and high order concatenation capabilities via the routing protocol for use in general LSP route selection. Currently, there are three higher-order concatenation types in SONET: - standard concatenation; - virtual concatenation; - arbitrary concatenation. The SONET signals that are produced by standard concatenation are STS-3c, STS-12c, STS-48c and STS-192c. Virtually concatenated signals are described in reference [14] and are denoted by STS-1-Xv where X is an integer. Note that in both [14] and updates to [15] Expires January 2002 [Page 9] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 during virtual concatenation the constituent STS-1s are transported individually across a SONET network and are "glued" together at the edge to provide an inverse multiplexing type of service. Arbitrary concatenation is the ability of two adjacent SONET systems to use any available time slots to compose an STS-Nc signal for arbitrary N. The main purpose of such a facility is to avoid the painful process of re-grooming SONET paths on a SONET line between these two systems. A system supporting arbitrary concatenation would by definition support standard concatenation. Virtual concatenation, on the other hand, is a separate capability of SONET edge equipment. In addition to the type of concatenation there may also be limits on the number of signals that can be concatenated or the minimum size of the signals that can be concatenated. Similar to the virtual concatenation of STS-1s, reference [14] also defines virtual concatenation for virtual tributaries. Only virtual concatenation of VT1.5 is currently being considered. To make matters even simpler, neither standard (or contiguous) concatenation nor arbitrary concatenation is being considered for virtual tributaries. Hence, if VT1.5s are supported on an interface then we will want a flag to indicate whether or not virtual concatenation is supported, and the minimum and maximum sizes of the concatenated signals that are supported. Note that it is important to know that a SONET-LSR can support virtual concatenation. For example, consider a 4-node linear SONET network with nodes A, B, C, and D, with there being only one link between any two adjacent nodes. Suppose the links between A and B and between C and D have sufficient bandwidth to establish an STS-3c trail. The link between B and C, however, has only 3 individual STSs available. In this case, in order for node A to compute a path from A to D with bandwidth equal to STS-3c, it is necessary for A to know whether or not nodes B and C support virtual concatenation. If they do, A would be able to compute a path for a signal of size STS-3c from A to D, because nodes B and C would be able to use virtual concatenation to glue the 3 individual STS-1s appropriately to carry the STS-3c signal over the link connecting them. 4.2.2. Link SDH/SONET Concatenation Capability TLV (LS-CC) The Link SDH/SONET Concatenation Capability TLV describes the SDH/SONET concatenation capabilities on a link. We will present first the TLVs for SDH. Similar TLVs can also be constructed for SONET. In IS-IS, this TLV is a sub-TLV of the Extended IS Reachability TLV with type TBD. In OSPF, this TLV is a sub-TLV of the Link TLV, with type TBD. The length is 8 octets. The value is coded as follows. 0 1 2 3 Expires January 2002 [Page 10] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|E| Reserved | Max AU-4s Contiguous | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max TU-2s Virtual | Max TU-2s Contiguous | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OSPF Link SDH Concatenation TLV. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 8 | A|E| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max AU-4s Contiguous | Max TU-2s Virtual | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max TU-2s Contiguous | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IS-IS Link SDH Concatenation TLV. The Max AU-4s Contiguous field gives the maximum number of AU-4s that can be concatenated in one block on a link. Zero means that AU- 4 concatenation is not supported. The Max TU-2s Virtual field gives the maximum number of TU-2s that can be virtually concatenated in one block on a link. Zero means that TU-2 virtual concatenation is not supported. The Max TU-2s Contiguous field gives the maximum number of TU-2s that can be contiguously concatenated in one block on a link. Zero means that TU-2 contiguous concatenation is not supported. However, some SDH devices have specific limitations. For instance, many SDH devices are only able to concatenate AU-4s in bundles of 2.exp(2*N), i.e. 4, 16, 64, etc. Since all possible limitations are hard to represent, we also propose an alternate way of representing the concatenation capabilities of a link by listing explicitly all of the types of concatenation supported. Flag A, if set to 1, indicates that only discrete levels of contiguous AU-4s, given by the 2 exp (2*N) formula, can be concatenated together. In that case, the Max AU-4s Contiguous field is the 'N' in the above formula. Flag E is set to 1 to indicate the extended form of the LS-C TLV. In that case, three lists are used to indicate all the discrete levels of concatenation supported, i.e. the size of each possible concatenated set. Each concatenation level is coded on 16 bits. The length of each list is given in terms of 16 bits entries. Expires January 2002 [Page 11] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 The first list is for the AU-4 contiguous concatenation, the second list is for the TU-2 virtual concatenation and the third list is for the TU-2 contiguous concatenation. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|E| Reserved | Max AU-4s Contiguous | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max TU-2s Virtual | Max TU-2s Contiguous | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Res| List 1 Length | List 2 Length | List 3 Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List 1: List of AU-4 Contiguous | | Concatenation Levels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List 2: List of TU-2s Virtual | | Concatenation Levels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List 3: List of TU-2 Contiguous | | Concatenation Levels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OSPF Extended Link SDH Concatenation TLV. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | A|E| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max AU-4s Contiguous | Max TU-2s Virtual | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max TU-2s Contiguous | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Res| List 1 Length | List 2 Length | List 3 Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List 1: List of AU-4 Contiguous | | Concatenation Levels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List 2: List of TU-2s Virtual | | Concatenation Levels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List 3: List of TU-2 Contiguous | | Concatenation Levels | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IS-IS Extended Link SDH Concatenation TLV. The reserved fields must be set to 0 when sent, and must be ignored on receipt. If no concatenation is supported on a link, this TLV must not be sent. Expires January 2002 [Page 12] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 4.3. Link Bundling Link bundling [9] has been proposed as a way to enhance the scalability of the routing protocol by grouping several parallel LSPs between two LSRs into a single, bundled link, and advertising this link as a single link in OSPF or IS-IS. Of course, there are some restrictions on the properties of the links that can be so bundled. 4.3.1. Bundling of SDH/SONET Signals For the case of SDH/SONET, each component of a bundled link can be a fiber or a wavelength that carries a SDH/SONET circuit or circuits. A fiber and a wavelength can be bundled only if they have the same TE characteristics from the SDH/SONET point of view. 4.3.2. Link SDH/SONET Bundle Size TLV (LS-BS) The Link SDH/SONET Bundle Size TLV specifies the number of identical components in a bundled link. In IS-IS, this TLV is a sub-TLV of the Extended IS Reachability TLV with type TBD. In OSPF, this TLV is a sub-TLV of the Link TLV, with type TBD. The length is 2 octets. The value is the number of components in the bundled link, and is coded in 2 octets. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Components | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OSPF Link SDH/SONET Bundle Size TLV. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 2 | Number of Components | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IS-IS Link SDH/SONET Bundle Size TLV. For instance, if a bundled link is made of 10 fibers with 40 wavelengths at STM-64, with the same SDH TE characteristics, the value of this TLV is 400. Thus, 400 SDH STM-64 signals are supported, and, if required, 400 instances of exactly the same signal can be allocated. This allows, for instance, a maximum of 400 x 64 x 3 (76800) VC-3s to be allocated. Expires January 2002 [Page 13] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 4.4. Link Protection Capability The protection capability that exists on a link is an important static capability that can be advertised through the routing protocol, and used by the route computation process to set up SDH/SONET circuits with appropriate protection characteristics. The Link Protection Type sub-TLV defined in [3], [4] does not completely cover SDH/SONET circuit requirements, since there are some special considerations that must be kept in mind when considering BLSR (SONET) or MS-SPRING (SDH) rings. In particular, it is very important to know the type of BLSR that a ring belongs to and the Ring ID associated with that BLSR. 4.4.1. Enhancement to Link Protection to Account for SDH/SONET Rings Special requirements apply to LSPs established over SDH/SONET crossconnects on BLSR rings. The BLSR standard requires that the same time slots be assigned to a given LSP on every BLSR link. In other words, if an LSP goes over successive links of a BLSR ring, it must have same time slots assigned to it on all of those links. If a LSP passes through multiple BLSRs, this requirement only applies individually to each BLSR. For example, say an STS-3c LSP uses three successive links of a BLSR. If time slots 4, 5, and 6 are assigned on the first hop of this LSP, then the same time slots must also be assigned on the other two links. To meet this requirement, the source of the circuit therefore needs to know the currently available channels/time-slots on each BLSR link. For example, an OC-192 link would require that all available (up to 192) channels be advertised. Clearly, this would result in very large IGP advertisements. Furthermore, every node would need to advertise this LSA whenever a channel was allocated or freed. This can be effectively achieved by applying the following mechanism in conjunction with a GMPLS-based control plane. Every node of a BLSR is aware of all the links of the BLSR and all available channels on those links. With this information, a BLSR node can advertise either one or two virtual links to every other node in the ring, since a node on a ring can reach any other node in two ways. These virtual tunnels, which have SDH/SONET link properties, are like LSP tunnels (or logical links from one node to the other). A virtual link consists of two or more physical links that belong to the BLSR. When a node advertises such a link, it should compute the Minimum Reservable Bandwidth and Maximum Reservable Bandwidth (see [3], [4]) for that link while considering the BLSR requirement and the currently available channels on the physical links comprising that virtual link. These computed values should be advertised in the Link Descriptor as described in [3], [4]. Expires January 2002 [Page 14] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 As explained in the next section, the Link Protection sub-TLV should have an additional protection bit that signifies Standard BLSR protection, and a field that contains a BLSR ID, which should be unique within an OSPF/IS-IS area. In order to meet the BLSR time-slot assignment requirement, a path computation algorithm should not consider two or more contiguous Standard BLSR links (either physical links or LSP tunnels) of a given BLSR in a shortest path computation. It can, however, consider multiple non-contiguous BLSR links in the shortest path computation. This may be the case, for example, when there are two interconnected BLSR rings, and a path computation engine computes a path whose first and third hops traverse a physical or virtual link on the first ring, while its second hop traverses a physical or virtual link on the adjacent interconnected BLSR ring. 4.4.2. Example Consider an OC-192 BLSR ring with 6 nodes A, B, C, D, E, F as shown below: +---+ +---+ | B | ------- | C | +---+ +---+ / \ / \ / \ +---+ +---+ | A | BLSR ID = 1 | D | +---+ +---+ \ / \ / \ / +---+ +---+ | F | ------- | E | +---+ +---+ Node A advertises virtual links corresponding to this BLSR. A has direct physical links to B and F, which can be advertised as such. Node A also creates virtual tunnels to nodes C, D, E and advertises these into its area. As a result, Node A provides the following view to the other nodes in its area: Expires January 2002 [Page 15] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 +---+ +---+ | B | | C | +---+ +---+ / / / /------+ / +------+ +---+ / +---+ | A | --------------------------- | D | +---+ \ +---+ \ +----+ \ \ \ ------+ \ \ +---+ +---+ | F | | E | +---+ +---+ Each connection between A and any other node on the BLSR ring could represent one or two virtual links from A to that node. It is up to node A to determine whether it to advertise one or two tunnels to every other node. If both links have similar Link Descriptor values, it may be sufficient to only advertise the virtual link that takes the shorter path. 4.4.3. Modified Link Protection Type TLV The Link Protection Type sub-TLV in [3], [4] needs to be enhanced to carry a BLSR Ring ID, which helps in two ways, as we explain shortly. First, it provides the setting up of SDH/SONET paths where each segment of the path is adequately protected by underlying SDH/SONET protection mechanisms. Second, it allows for the path computation algorithm to meet the BLSR time slot assignment requirement outlined in the previous section. To understand why the BLSR Ring ID is useful, consider the following example. Consider a network with 6 nodes A, B, C, D, E, and F as shown below: Expires January 2002 [Page 16] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 +--------+ +--------+ | B |---------| C | | |---------| | +--------+ +--------+ / / \ \ / / \ \ / / \ \ +--------+ +--------+ | A | | D | | | | | +--------+ +--------+ \ \ / / \ \ / / \ \ / / +--------+ +--------+ | F |---------| E | | |---------| | +--------+ +--------+ Suppose that these nodes sit on two parallel BLSR rings, an inner ring with Ring ID = 1 and outer ring with Ring ID = 2. When an LSP is being created from node A to node D, it is technically possible for the path for that LSP to go from A to B on the inner ring, from B to C on the outer ring, and C to D again on the inner ring. Not only is this inefficient, it also does not work well with BLSR protection. In fact, such an assignment of links to an LSP does not provide any protection at all if node B were to fail. Instead, if the LSP path were to choose all the links from same ring, it would provide protection for the LSP even when node B failed. Given the above, it is necessary for a path computation entity to know BLSR Ring ID of each ring in its purview, and this parameter should therefore be advertised in the Link Protection Type sub-TLV. Finally, as explained earlier, the Bellcore standards impose the requirement that the same time slots be assigned to an LSP on each link of a BLSR ring. This imposes the requirement that only one physical or virtual link of a BLSR ring may be used by a path passing through a BLSR ring. For the path computation algorithm to be able to do this efficiently, the BLSR Ring ID is again handy, and therefore needs to be advertised in the Link Protection Type sub- TLV. Note that it is entirely possible for the nodes on a BLSR ring to run proprietary algorithms that do away with the requirement to have the same set of time slots assigned to an LSP at each hop of the ring. (Some vendors have, in fact, implemented protocols for this case, which run among the nodes on a BLSR ring.) Given this scenario, it is also necessary for the nodes in a network to know whether or not a given BLSR ring requires the time-slot assignment required by the Bellcore standards. This requires that the Link Expires January 2002 [Page 17] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 Protection Type sub-TLV also provide a way to distinguish between standard BLSR rings and enhanced BLSR rings of the type just described. To provide all of the necessary information discussed above, the Link Protection Type sub-TLV needs to be modified as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 14 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Link Prot. Type| Working Pri | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BLSR Ring ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It may also be useful for the Link Protection Type values to be defined as integer values instead of bit values, since it is not possible for a link to provide multiple types of protection. (Note that this is different than the encoding for the Link Protection sub-object in the signaling protocols [11]. This is because when signaling for the type of desired protection on a link/hop taken by a SDH/SONET LSP, it is possible to indicate a multiplicity of values, leaving the actual choice to be a local decision, since the circuit in question may be willing to accept any form of protection from among the specified set. This is not true, however, when one is merely describing the types of protection that a link supports, which is the case here.) Thus, Link Protection Type values should have these additional values: TBD1 : Standard BLSR TBD2 : Enhanced BLSR 5. Dynamic Link Capabilities We now review the dynamic capabilities of a link that must be advertised in the routing protocol. Clearly, the most important dynamic link capability that needs to be advertised is information on the resources that are used on each link. That is, the operational status of a link. The other parameters that are discussed here pertain to some optimizations that are possible in the advertised information when contiguous blocks of signals from the SDH/SONET multiplex are occupied on a link. 5.1. Overview of Bandwidth Status Reporting in SDH/SONET There is a trade off possible between the amount of detail in the bandwidth resource information reported via a link state routing protocol, the frequency or conditions under which this information Expires January 2002 [Page 18] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 is updated, the percentage of connection establishments that are unsuccessful on their first attempt, and the extent to which network resources can be optimized. Consider first the relatively simple structure of SONET and its most common current and planned usage. DS1s and DS3s are the signals most often carried within a SONET STS-1. Either a single DS3 occupies the STS-1 or up to 28 DS1s (4 each within the 7 VT groups) are carried within the STS-1. With a reasonable VT1.5 placement algorithm within each node it may be possible to just report on aggregate bandwidth usage in terms of number of whole STS-1s (dedicated to DS3s) used and the number of STS-1s dedicated to carrying DS1s and the number of VT1.5s currently allocated for this purpose. This way a network optimization program could try to determine the optimal placement of DS3s and DS1s to minimize wasted bandwidth due to half-empty STS-1s at various places within the transport network. Similarly consider the set of super rate SONET signals (STS-Nc). If the links between the two switches support arbitrary concatenation then the reporting is particularly straightforward since any of the STS-1s within an STS-M can be used to comprise the transported STS- Nc. However, if only standard concatenation is supported, then things get a bit trickier since there are constraints on where the STS-1s may be placed. SDH has still more options and constraints. Hence, it is not yet clear which is the best way to advertise bandwidth resource availability/usage in SONET/SDH. Due to the multiplexed nature of the signals, however, the reporting of bandwidth particular to signal types rather than as a single aggregate bit rate is highly desirable. 5.2. Link Capacity Allocation in SDH/SONET A signal is allocated in the SDH/SONET multiplex of a link when an SDH/SONET-LSP is established through that link using that signal. A signal is released in the multiplex of a link when the corresponding SDH/SONET-LSP is released. When a signal is allocated, the lower order signals that could be part of it are not advertised. A signal is treated as a whole and its internal structure is unknown to the LSRs at each end of the link. If the signal is channelized, it is under the control of the node that initiated the corresponding SDH/SONET-LSP. For instance, if a VC-3 is allocated on consecutive links to build an SDH-LSP between two nodes, these VC-3s are considered as a whole by each intermediate SDH-LSR. The SDH-LSP is either an end-to-end SDH circuit between two end systems, or a tunnel between two edge LSRs of that routing domain. Only the source node of an SDH-LSP can further channelize it. No intermediate LSR (or indeed any other LSR in the entire domain) needs to be aware of that channelization. Thus, no channelization information is advertised. Expires January 2002 [Page 19] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 However, an SDH-LSP could be advertised in a routing domain as a virtual link, i.e. a Forwarding Adjacency (FA) as defined in [8]. In that case, the corresponding bandwidth becomes available again to the users, but differently. The FA is between the head-end LSR that advertises this virtual link and the tail-end LSR of that virtual link. No intermediate LSR between the two ends participates in any further structuring of this signal. For instance, if a VC-3 is allocated on consecutive links to build an SDH-LSP between two LSRs, and if the head-end LSR advertises this SDH-LSP as a FA, then the VC-3 appears as a new link in the topology of that routing domain. This SDH-LSP and can be channelized to route sub-SDH-LSPS. This channelization must be then advertised in the routing domain to all SDH-LSRs. Each time a signal is allocated in the SDH/SONET multiplex, an LSA/LSP should be advertised to all routers in the same routing domain (e.g. OSPF area). In order to reduce the number of advertised LSA/LSPs, an implementation could decide to wait during a given time to collect several signal allocations for a particular link, before sending updated LSAs/LSPs. Specification of such behavior, however, is beyond the scope of this document. Note that information about SDH/SONET signal concatenation does not need to be advertised by the routing protocol. The only relevant information for an SDH-LSR is the fact that a signal (bandwidth and position) is available or not, but not that it belongs to a bigger concatenated signal. 5.2.1. Link SDH/SONET Allocation TLV (LS-A) The Link SDH/SONET Allocation TLV is used to advertise a list of signals that have been allocated in the SDH/SONET multiplex of a link. Since the bandwidth used by these signals is allocated to LSPs, these signals cannot be used to route new LSPs until they are released. This TLV is a list of labels allocated at a link, represented and coded using the multiplex based labeling and coding defined in [12]. (Of course, there is no need to advertise MPLS labels in routing protocols. We refer to these labels here since their structure and coding, as proposed in [12], directly reflect the signals that we wish to identify.) In IS-IS, this TLV is a sub-TLV of the Extended IS Reachability TLV with type TBD. In OSPF, this TLV is a sub-TLV of the Link TLV, with type TBD. The length is the length of the Label Value List plus 4 octets. The value is coded as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires January 2002 [Page 20] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber Identifier | Wavelength Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Label Value List | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OSPF Link SDH/SONET Allocation TLV. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber Identifier | Wavelength Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Label Value List | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IS-IS Link SDH/SONET Allocation TLV. A fiber identifier and a wavelength identifier indicate the particular link or link component to which the list is relevant. These two identifiers are generated by the SDH/SONET-LSR that advertises the LSA/LSP. If the link is not a bundle, the SDH/SONET- LSR allocates a value such that the extension from a single link to a bundled link could be possible without re-advertising all the LSA/LSPs already advertised. Each label value is coded using the 32-bit encoding defined in [12]. A single TLV cannot span two link components, and if nothing is allocated, no TLV is advertised. 5.3. Grouping of Contiguously Allocated Signals The main idea behind grouping contiguously allocated signals is to avoid the advertising of excessive information in the routing protocols. In the worst case, if each lower order signal were advertised independently, a maximum of N*84 VC-11s signals could be advertised per channelized STM-N link. When multiplied by the total number of links in the topology, this could be a huge number to advertise and to maintain in a routing database. To help solve this issue, contiguous allocated signals could be grouped and advertised more economically. Contiguously allocated signals that span a higher-order signal could be advertised by advertising only the higher-order signal. The only Expires January 2002 [Page 21] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 important information to advertise here is the fact which lower order signals are unavailable and what their positions are. Only the SDH/SONET LSR that originates an LSA/LSP has the capability to group contiguously allocated signals into a single LSA/LSP. The grouping capability and the fact that when a higher order signal is allocated there is no need to advertise its lower order signals (except in case of FA), increase considerably the scalability of the proposed solution. 5.3.1. Link SDH/SONET Block Allocation TLV (LS-BA) The Link SDH/SONET Block Allocation TLV is optional. It can be used to complement the Link SDH Allocation TLV, since it provides an alternative way to represent the allocated signals. It assumes that a large number of allocated signals are contiguous, and can therefore be represented simply by specifying a starting signal and an ending signal. This TLV is made of a list of block entries, where each entry identifies a starting signal in one fiber and wavelength, and an ending signal in one fiber and wavelength. The two fibers may be different. Each block entry is made of 16 octets as described shortly, and the starting signal, the ending signal, and all intermediate signals are assumed to be allocated. If the wavelength is not significant it must be set to zero. This TLV implies that an order is defined among the fibers, and among the wavelengths inside each fiber. This order, however, is simply defined by the advertising SDH-LSR. In IS-IS, this TLV is a sub-TLV of the Extended IS Reachability TLV with type TBD. In OSPF, this TLV is a sub-TLV of the Link TLV, with type TBD. The length is the length of the list of Block Entries in octets (multiple of 16). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | List of Block Entries | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OSPF Link SDH/SONET Block Allocation TLV. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Expires January 2002 [Page 22] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | List of Block Entries | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IS-IS Link SDH/SONET Block Allocation TLV. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Fiber Id. | Starting Wavelength Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ending Fiber Id. | Ending Wavelength Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ending Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Block Entry. The Link SDH/SONET Allocation TLV and Link SDH/SONET Block Allocation TLV can overlap and advertise signals in common. Each TLV must be advertised in a separate LSA/LSP. 6. Interworking Capabilities The capabilities described in the following subsections refer to some auxiliary static link capabilities that are beyond the basic capabilities discussed in Section 4. In particular, they refer to capabilities that determine how SDH routers with different processing capabilities may be interconnected, and to the various types and levels of interworking possible between SONET and SDH equipment. 6.1. Interconnection Capability The SDH multiplex (since it is not a true tree; see [5]) allows for the transport of the same signal inside different higher order signals. For instance, a VC-3 can be transported in either an AU-3 or a TU-3. Possible interconnections are defined in G.707 section 6.4 and are discussed in [5] and [12]. Thus, SDH interconnection allows for an increase in the end-to-end connectivity capability when not all links in a given routing domain have the same structure. 6.1.1. Router SDH Interconnection Capability TLV (RS-IC) This TLV describes the SDH interconnection capabilities of a particular SDH-LSR. Expires January 2002 [Page 23] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 In IS-IS, this TLV is a new TLV with type TBD. In OSPF, this TLV is a new top-level TLV, with type TBD. The value is coded in three flags as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|B|C| Reserved | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OSPF Router SDH Interconnection Capability TLV. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length=1 |A|B|C| Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IS-IS Router SDH Interconnection Capability TLV. Each flag indicates a type of SDH interconnection that may happen: - At the VC-3 level between a AU-3 and a TU-3 : flag A, - At the TUG-2 level between a VC-3 and a TUG-3: flag B, - At the VC-11 level between a TU-12 and a TU-11: flag C. A flag equal to 1 indicates that the corresponding interconnection is supported by the SDH-LSR, a flag equal to 0 indicates that it is not. The reserved field must be set to 0 when sent, and must be ignored when received. 6.2. Interworking Capability Internetworking between SDH and SONET may be needed for different reasons. For instance, it may happen between North American and European operators in order to provide connectivity between them. In that case, internetworking occurs between a SONET routing domain and an SDH routing domain, and requires an inter-domain routing protocol (it is, therefore, not in the scope of this document, but the reader is referred to [16] for an overview of issues and requirements). However, internetworking may also be useful for a single operator providing both SDH and SONET services in the same routing domain. This is the case that we focus on in this section. This routing domain may or may not be divided into areas. We assume that an SDH- SONET-LSR (SS-LSR) advertising the RS-SI TLV could be an intra-area SS-LSR or an area border SS-LSR. First consider the case where the domain is divided into areas. For instance, if one OSPF area is SONET based, and the backbone area is SDH based, different area border SS-LSRs between these two areas Expires January 2002 [Page 24] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 could advertise different internetworking capabilities. For a source node to be able to compute a source route, it is important that it be able to compute a source route through a border SS-LSR that has the right internetworking capabilities. Next consider the case where there are no areas, and a flat OSPF or IS-IS routing domain is used, mixing both SDH and SONET types of network. No inter-area exchange of information needs to take place. This is the simplest case, and is directly supported by this section. The SDH-SONET internetworking scenarios supported in this specification cover: - Internetworking between STM-1 (SDH) and STS-1 (SONET). - Internetworking between STM-Mc (SDH) and STS-Nc (SONET), where N=3*M. - Internetworking between STM-1 and STS-1 lower order signals. An SDH-SONET-LSR capable of acting as a gateway should advertise its particular internetworking capabilities to every other LSR in the same routing domain. SONET networks are based on STS-1 frames while SDH networks are based on STM-1 frames. An STS-1 frame is made of a transport overhead (corresponding to the SDH Section overhead) and a SPE (corresponding to the SDH VC-3 plus two columns of fixed stuff). There is no equivalent for an STS-1 frame in the SDH standard, but an STS-1 frame would correspond to an SDH frame build with a single AU-3. The main tributary signals that can be transported by an STS-1 are DS-3 (44736 kbit/s), DS-2 (6312 kbit/s), DS-1c (3152 kbit/s), E1 (2048 kbit/s) and DS-1 (1544 kbit/s). Only one DS-3 can be transported per STS-1. The same tributary signals may be transported over SDH, except the DS-1c that has no equivalent in SDH and that will be not further considered here. Internetworking allows transporting these signals end-to-end over a hybrid network. SDH networks support both AU-3 and AU-4, however SDH mainly uses AU- 4s. Therefore a SONET signal must be mainly demultiplexed, transformed and remultiplexed within an SDH AUG via the TUG-3/VC- 4/AU-4 route. Up to three DS-3s can be transported per STM-1 signal. Note that concatenated SONET signals, like STS-3c, directly correspond to the SDH AU-4 structure and therefore no format conversion is necessary, although certain internetworking issues still remain due to overhead processing differences. 6.2.1. Router SDH-SONET Interworking Capability TLV (RS-SI) Expires January 2002 [Page 25] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 This TLV describes a set of SDH-SONET internetworking capabilities. Internetworking is realized through the use of an SDH-SONET gateway. Each gateway has a subset of its interfaces being SDH capable, and a subset being SONET capable. A gateway always terminates the Regenerator Section and Multiplex Section overheads on the SDH side, and the Section and Line overheads on the SONET side. The Path overhead may or may not be terminated on the gateway, depending on the scenarios. Of course, either the Path overhead is terminated on both the SDH and SONET sides, or it is not terminated at any side. In IS-IS, this TLV is a new TLV with type TBD. In OSPF, this TLV is a new top-level TLV, with type TBD. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|B|C|D|E|F|G|H|I|J|K| Reserved| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OSPF Router SDH-SONET Internetworking Capability TLV. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length=4 |A|B|C|D|E|F|G|H|I|J|K| Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IS-IS Router SDH-SONET Internetworking Capability TLV. Each flag indicates the type of SDH-SONET internetworking that is supported by the gateway LSR: - Flag A: between STM-1 (SDH) and STS-1 (SONET) through AU-4. - Flag B: between STM-1 (SDH) and STS-1 (SONET) through AU-3. - Flag C: between STM-Mc (SDH) and STS-Nc (SONET), where N=3*M, - Flag D: between TUG-2 (SDH) and VT Group (SONET) through VC-4, - Flag E: between TUG-2 (SDH) and VT Group (SONET) through VC-3, - Flag F: between TU-2 (SDH) and VT6 (SONET) through VC-4, - Flag G: between TU-2 (SDH) and VT6 (SONET) through VC-3, - Flag H: between TU-12 (SDH) and VT2 (SONET) through VC-4, - Flag I: between TU-12 (SDH) and VT2 (SONET) through VC-3, - Flag J: between TU-11 (SDH) and VT1.5 (SONET) through VC-4 - Flag K: between TU-11 (SDH) and VT1.5 (SONET) through VC-3. The length field indicates the maximum value of M supported for internetworking. The reserved field must be set to zero upon transmission, and ignored on receipt. Expires January 2002 [Page 26] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 6.2.2. Interworking between STM-1 and STS-1 In one direction, from STS-1 to STM-1, this internetworking is accomplished by extracting the SPE of an STS-1, transforming the SPE into a VC-3 via pointer processing and the removal of two columns of fixed stuff bytes, and processing the VC-3 via the TUG-3/VC-4/AUG route as shown below. In the other direction, from STM-1 to STS-1, exactly the opposite occurs. |->STM-1 | |->VC-4-->AU-4->AUG-| OC-1/ |3 STS-1-| |->TU-3->TUG-3-| | | |SPE->trans->VC-3-| Figure: STS-1 to STM-1 mapping through AU-4. Using this capability, three independent DS-3 signals, each transported by a SONET STS-1 signal, can be multiplexed and transported in a single STM-1 signal. Alternatively, the VC-3 could be transported via the AU-3/AUG route as described below. Again three independent DS-3 signals transported over SONET can be transported over SDH. |->AUG->STM-1 OC-1/ |3 STS-1-| |->AU-3-| | | |SPE->transform->VC-3-| Figure: STS-1 to STM-1 mapping through AU-3. Note that if a single DS-3 has to be transported end-to-end, it can imply on the SDH side that a whole VC-4 needs to be equipped to the end, even if the two other VC-3 components are not used. Ideally, the routing algorithm should know the details of both the SDH and the SONET clouds in order to find the path that minimizes the number of SDH VC-3s that will not be used (i.e. to minimize internal fragmentation of VC-4s due to the internetworking). 6.2.3. Interworking between STM-Mc and STS-Nc Internetworking between STM-1 and STS-3c is simpler to implement since the two frames have the same structure. The standard SONET concatenation only allows STS-N multiplexing where N is a multiple of 3. This helps with SDH internetworking. Likewise, internetworking between STM-Mc and STS-Nc, where N=3*M is also simple to implement. Expires January 2002 [Page 27] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 6.2.4. Interworking between STM-1 and STS-1 Lower Order Signals Internetworking is also possible between the SDH TUG-2, TU-11, TU-12 or TU-2 and respectively the SONET VT Group, VT1.5, VT2 and VT6. Since the corresponding sub-signals have the same structure, this internetworking should be straightforward. 6.3. Overhead Byte Differences between SDH and SONET Differences appear in the way that SDH and SONET define some bytes in the overheads. Differences may appear in pointers (e.g. H1), section overhead (e.g. JO, K1, K2, S1) and in the path overhead (e.g. J1, B3, G1, K3). An SDH-SONET gateway must deal with these differences, but the processing is outside of the scope of this document. In the case of STM-1/STS-1 internetworking, the difference in the path overhead bytes is such that the path must be terminated on each side of the gateway. In the case of STM-1/STS-3c internetworking, the SDH and SONET paths do not need to be terminated at the gateway. 7. Updating Routing Databases The maintenance of the routing database and the generation of LSA/LSPs can be complex processes. An SDH/SONET-LSR should try to minimize the amount of routing information it floods, for instance by replacing a long list of labels advertised in an LS-A TLV by a single block advertised in a LS-BA TLV. Each time a signal is allocated or released this information must be flooded to all SDH/SONET-LSRs in the routing domain. This can result either in the generation of a new LSA/LSP (for instance when the first signal is allocated on a link), or the update or removal of an existing LSA/LSP. Generating an LSA/LSP is a straightforward operation. However, an SDH-LSR should take care to neither advertise too many small LSA/LSPs, nor too many big ones. When an LSA/LSP is updated, it is re-flooded in the routing domain. Each receiving LSR must check each signal or each block in the updated LSA/LSP in order to detect new or obsolete signals. This can be time consuming. For instance, when one single unique signal is removed from an LS-A TLV in an LSA/LSP, all the signals that did not change are re- flooded and must be checked by each SDH/SONET-LSR in order to detect the missing signal that must be removed. Expires January 2002 [Page 28] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 Removing an LSA is done in OSPF by prematurely aging the LSA. The LSA is re-flooded with an LSA age equal to MaxAge. Each SDH-LSR receiving an existing LSA with MaxAge removes it from its database, i.e. it must deal with each individual label or block advertised in the LSA. Removing an LSA is done in IS-IS in a similar way. Each LSP has a RemainingLifeTime field indicating the remaining lifetime of the LSP. This field is initialized with MaxAge and the LSP is discarded when it reaches zero. To remove an LSP, the LSP is flooded with a zero remaining lifetime. Sometimes it can be more complex, for instance if an existing LSA/LSP must be split in two, and replaced by two other LSA/LSPs, or if a list of individuals labels in a LS-A TLV is to be replaced by a block entry in another LSA/LSP. The routing database must count the number of times a signal is advertised as being allocated by different LSA/LSPs, and can only remove a signal if that signal is not being advertised anymore by any LSA/LSP. This rule allows for optimization between LS-A and LS- BA TLVs. One could observe that the OSPF and IS-IS routing protocols are not well adapted for the granularity required by the SDH routing. Everything is based on the concept of LSA/LSP. Each LSA/LSP is individually identified, refreshed, and removed. Indeed, this is the LSA/LSP that is maintained, and indirectly its content. This is suitable in an environment where each LSA/LSP is an atomic set of information, e.g. when one link is seen as whole and advertised by one LSA/LSP. However, this is not suitable when a link is made of hundreds, or thousands, of small elements that must be individually controlled. It is absolutely not scalable to advertise each signal in a different LSA/LSP. As a result, we must group individual signals per LSA/LSP using adequate TLVs. OSPF and IS-IS imply two major problems. First, each LSA/LSP must be refreshed periodically to avoid age timeout and automatic removal. Potentially, a huge amount of information must be re-flooded and treated periodically. Second, it is impossible to indicate explicitly that a signal must be added or removed since it is part of an LSA/LSP. We must each time re-flood the complete LSA/LSP (with all the signals), but with the new signal (to simulate an add operation) or without a previous signal (to simulate a remove operation). Indeed, the main problem comes from the fact that OSPF and IS-IS were designed to support link states with very simple and not very dynamic states. What we really need to support SDH/SONET routing is a protocol able to maintain a dynamic database with add and remove operations per list of database entries. Expires January 2002 [Page 29] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 8. Size of Routing Protocol PDUs OSPF runs over IP and the length of OSPF packets can be up to 65535 octets (including the IP header). OSPF relies if necessary on the IP fragmentation to transmit large packets. However this is not recommended and it is suggested to split OSPF packets that are too large into several smaller packets. This is possible without any loss of functionality. An OSPF packet can contain several LSAs. The OSPF Opaque LSA has a length field of 16 bits giving the length of the LSA, including the header. There is no particular issue due to size of SDH routing information to transport. IS-IS transports routing information in LSPs (Link State PDUs), the equivalent of OSPF LSAs. An LSP is made of a fixed header and a list of TLVs. Because a Link State PDU is limited in size to ReceiveLSPBufferSize, an LSR may use multiple LSPs to convey this information if it doesn't fit in one single PDU. The ReceiveLSPBufferSize is the maximum size of LSP that all routers must be able to receive, its default is 1492. Each LSP is identified by an LSP-ID coded on 8 octets but allows only differentiating 256 different LSPs (LSP number sub-field) advertised from the same router. In addition, the length of each TLV is limited to 255 octets. The Extended IS Reachability TLV defined in [4] can itself contain sub-TLVs as defined in our document. The length of each such sub-TLV is limited to 244 octets. It results that the routing information must be fragmented in small sub-TLV sets. Even if the maximum length of an LSP is extended we are limited to 256 LSPs advertised per router. In some network this could not be sufficient to allow SDH routing as described in this document (to be further investigated). 9. Security Considerations Security considerations are not discussed in this version of the document. 10. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] E. Mannie (Editor), "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", Internet Draft, Work in Progress, draft- ietf-ccamp-gmpls-architecture-00.txt, June 2001. Expires January 2002 [Page 30] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 [3] K. Kompella et al, "OSPF Extensions in Support of Generalized MPLS,÷ Internet Draft, Work in Progress, draft-kompella-ospf- gmpls-extensions-01.txt, February 2001. [4] K. Kompella et al, "IS-IS Extensions in Support of Generalized MPLS,÷ Internet Draft, Work in Progress, draft-ietf-isis-gmpls- extensions-02.txt, March 2001. [5] G. Bernstein, E. Mannie, V. Sharma, "Framework for MPLS-based Control of SDH/SONET Networks,÷ Internet Draft, Work in Progress, draft-bms-optical-sdhsonet-mpls-control-frmwrk-01.txt, July 2001. [6] D. Katz, D. Yeung, K. Kompella "Traffic Engineering Extensions to OSPF", draft-katz-yeung-ospf-traffic-05.txt, Internet Draft, Work in Progress,June2001. [7] H. Smith, T. Li, "ISIS Extensions for Traffic Engineering", draft-ietf-isis-traffic-03.txt, Internet Draft, Work in Progress, June 2001. [8] K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE", draft-ietf-mpls-lsp-hierarchy-02.txt, Internet Draft, Work in Progress, February 2001. [9] K. Kompella, Y. Rekhter, L. Berger, "Link Bundling in MPLS Traffic Engineering", draft-kompella-mpls-bundle-05.txt, Internet Draft, Work in Progress, February 2001. [10] R. Coltun, RFC 2370, "The OSPF Opaque LSA Option", July 1998. [11] P. Ashwood-Smith, L. Berger (Editors), "Generalized MPLS Signaling Functional Description", draft-ietf-mpls-generalized signaling-04.txt, Internet Draft, Work in Progress, May 2001. [12] E. Mannie (Editor),"GMPLS Extensions for SDH/SONET Control", draft-ietf-ccamp-gmpls-sdh-sonet-01.txt, Internet Draft, Work in Progress, June 2001. [13] ITU-T Recommendation G.707,"Network Node Interface for the Synchnonous Digital Hierarchy", 1996. [14] N. Jones and C. Murton, ),"Extending PPP over SONET/SDH with Virtual Concatenation: Lower Order and Higher Order Payloads", draft-ietf-pppext-posvcholo-02.txt, Internet Draft, Work in Progress, December 2000. [15] American National Standards Institute, "Synchronous Optical Network (SONET) - Payload Mappings" ANSI T1.105.02-1998. Expires January 2002 [Page 31] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 [16] G. Bernstein, et al,"Optical Inter-Domain Routing Considerations", draft-bernstein-optical-bgp-01.txt, Internet Draft, Work in Progress, July 2001. 11. Acknowledgments Eric Mannie would like to thank Paolo Casaschi, Pedro Falcao, Gzim Ocakoglu for their valuable help and comments on an initial draft that is used in this work (names sorted by alphabetical order), and Jose Miguel Santos for his help on SDH-SONET internetworking issues. 12. Author's Addresses Eric Mannie Greg Bernstein GTS Network Services Ciena Corporation RDI Department, Core Network 10480 Ridgeview Court Technology Group Terhulpsesteenweg, 6A Cupertino, CA 94014, USA 1560 Hoeilaart, Belgium Phone: +1(408) 366-4713 Ph: +32-2-658.56.52 Email: greg@ciena.com Email: eric.mannie@gtsgroup.com Bala Rajagopalan Mike Raftelis Tellium, Inc. White Rock Networks, Inc. 2 Crescent Place 18111 Preston Road, Suite 900 P.O. Box 901 Dallas, TX 75252, USA Oceanport, NJ 07757-0901, USA Ph: +1(972)588-3728 Ph: +1 732 923 4237 Email: MRaftelis@WhiteRockNetworks.com Email: braja@tellium.com Dimitri Papadimitriou Alcatel IPO-NSG Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: Dimitri.Papadimitriou@alcatel.be Suresh Katukam Vishal Sharma Cisco Systems Metanoia, Inc. 1450 N. McDowell Blvd 335 Elan Village Ln., Unit 203 Petaluma, CA 94954-6515 USA San Jose, CA 95134-2539, USA Ph: +1 (707) 285-5427 Ph: +1 (408) 943 1794 Email: skatukam@cisco.com Email: v.Sharma@ieee.org Expires January 2002 [Page 32] draft-mannie-mpls-sdh-ospf-isis-01.txt July 2001 Expires January 2002 [Page 33]