Internet Draft Network Working Group E. Mannie Internet Draft GTS Network Services Expiration Date: January 2001 G. Bernstein Ciena Document: draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 Extensions to OSPF and IS-IS in support of MPLS for SDH/SONET Control 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 specifies and suggests extensions to the OSPF and IS- IS routing protocols in order to support the routing of dynamically established SDH/SONET circuits using the MPLS architecture. 1. Introduction A framework for controlling SDH by MPLS was presented in [2] and some of the issues concerning SONET and MPLS were presented in [8]. This document is based on TE extensions defined in [3] and [4]. It uses also some TLVs and the notion of Forwarding Adjacency defined in [5]. It supports Link Bundling as defined in [6]. Its supports some forms of SDH-SONET internetworking. Several new TLVs based on [3], [4] and [7] are suggested. Routing information is transported by OSPF in Link State Advertisements (LSAs) grouped in OSPF PDUs, and is transported by IS-IS in Link State PDUs (LSPs). Two particular sets of information must be transported by a routing protocol to enable SDH/SONET routing. A static set of information describes the capabilities of an SDH-LSR (SONET-LSR) and its SDH (SONET) links independently of their usage. A dynamic set of information describes the resources (signals) that are used at each link, i.e. the operational status of Mannie, E., Bernstein, G. [Page 1] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 a link. For each of these sets, new TLVs are defined in the following. TLVs regarding the static capability of an SDH-LSR and its links: - LS-MC TLV : Link SDH (SONET) Multiplex Capability TLV. - LS-C TLV : Link SDH (SONET) Concatenation TLV. - LS-BS TLV : Link SDH Bundle Size TLV. - RS-IC TLV : Router SDH Interconnection Capability TLV. - RS-SI TLV : Router SDH SONET Internetworking TLV. TLVs regarding the current status of a link: - LS-A TLV : Link SDH Allocation TLV. - LS-BA TLV : Link SDH Block Allocation TLV. A link between two adjacent LSRs is defined in [5] as one Logical Control Channel (LCC) and one or more fibers with the same TE characteristics. If there is more than one fiber in a link, the bundling technique of [6] is applied. The OSPF and IS-IS TE routing extensions for optical switching of [5] apply to all the fibers in that link. The fundamental idea of bundling is that all components must have exactly the same Traffic Engineering (TE) characteristics. If WDM is used for some fibers, we assume that each wavelength will act as a separate (virtual) fiber. It results that each component of a bundle must have the same SDH/SONET multiplex capabilities and concatenation capabilities as defined hereafter. The two corresponding TLVs (LS-MC and LS-C) are specified once, and apply to each component. No per component information or identification is required for these TLVs. The Link SDH Bundle Size TLV defined hereafter gives the total number of (identical) components in a bundle. However, the usage of each component may differ completely. Each component could be structured (i.e. channelized or equipped) completely differently from the others. For instance, with a 2- fibers bundled link, the first component (fiber) could be structured in STM-4s while the second component (fiber) could be structured in VC-3s. In the same way, each STM-i of an STM-N (N>1) could also be structured completely differently from the others. We cannot simply represent the total number of signals that are allocated per bandwidth level (e.g. a E1 or E3) on a given [bundled] link. We need also to know where they are allocated and their types. This is of paramount importance, since when a signal is allocated, it does not only consume bandwidth at a given position but it also imposes the structure of some free part of the SDH multiplex. A smart routing algorithm could need to allocate some signals in a specific STM-i of a given component in order to maintain enough free space to further setup other higher order signals in another STM-j. Since we cannot presume the type of TE routing algorithm that will Mannie, E., Bernstein, G. [Page 2] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 be used, we cannot restrict or simplify the information advertised by the routing protocols. Holes (fragmentation) will be created in the SDH multiplex during the lifetime of the network. A routing algorithm needs to know where these holes are, their types, and how big they are in order to route new demands. Note that one demand could be satisfied by the sum of all holes, but could be infeasible in practice, since there is no single hole able to fit it. For instance, if we know that 21 VC-12s are allocated in an STM-N link, it does not indicate if they are all allocated in the same VC- 3 of single STM-1, or if they are split in different VC-3s of different STMs. Moreover, holes cannot be filled with any type of signal even if the bandwidth is sufficient since the SDH multiplexing rules must be respected. It results that signals allocated in a [bundled] link must be individually advertised. However they may be grouped together in a higher order signal advertisement when this higher order signal is completely filled. For instance, when a complete VC-3 if filled, it is better to advertise a single VC-3 rather than advertising each sub-signal independently. A label such as defined in [2] identifies a signal and its position in a particular STM-N multiplex. Note that a signaling protocol also needs to identify the fiber, or the fiber and the wavelength, corresponding to the STM-N. In a similar way, if a link is bundled, the routing protocol will have to advertise the corresponding bundle component on which a signal is allocated. We are now facing the problem of having potentially to 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 at the bundled link, and that must be advertised to all SDH-LSRs in the same routing domain. Even with some 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 amount of signals allocated contiguously, the dynamic of the demands in terms of duration and/or bandwidth, etc. We propose a simple dual representation scheme of the allocated signals using a mandatory representation based on the labeling defined in [2], and an optional per block representation. Each one is using a different TLV in a separate LSA/LSP. The mandatory representation has the advantage of being compatible with the label representation for the signaling protocol. Other representations are for further study. Mannie, E., Bernstein, G. [Page 3] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 A way to cope with the huge amount of routing information to be distributed, consist also in limiting the size of a routing domain, e.g. by using smaller OSPF areas. 1.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1.2 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 Multiprotocol 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) VC-n Virtual Container-n (SDH) VTn Virtual Tributary-n (SONET) 2.1. Link SDH Multiplex Capability (LS-MC) TLV: The Link SDH Multiplex Capability TLV describes the SDH STM-1 multiplexing structure available on a link. It indicates precisely the signals that can be allocated in an STM-1 multiplex, not the actual allocation. Signals actually allocated on that link are advertised using the LS-A or LS-BA TLVs. Signal concatenation is covered by the Link SDH Concatenation TLV. The Link SDH Multiplex Capability TLV must be used with two other TLVs defined in [2]: the Link Type TLV and the Link Media Type TLV. The Link Type TLV must have a value of 200 to indicate that the link is a TDM link. The Link Media Type TLV must have a value of 3072 + N, with 1 <= N <= 3072 to indicate an STM-N. The Link SDH Multiplex Capability TLV describes the multiplex capabilities of one single STM-1. If a link is an STM-N, N > 1, it is assumed that all STM-1 components of that STM-N have the same multiplexing capabilities. 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 Mannie, E., Bernstein, G. [Page 4] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 type TBD. The length of this TLV is one octet. The value is coded on 8 bits and is defined as a vector of flags. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OSPF Link SDH 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 | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IS-IS Link SDH Multiplex Capability TLV. Each flag indicates the capability to multiplex a given signal in its direct higher order signal. A flag to 1 indicates that the multiplexing capability is supported, 0 indicates that the capability is not supported. Bit 1 is the highest order bit of the flag field. - 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. 2.2. The Structure of SONET and its Multiplex Capabilities Mannie, E., Bernstein, G. [Page 5] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 In a previous draft on SONET and MPLS the basic SONET signal, STS-1, was given and super rate signals, known as STS-Nc, were described [8]. Since an MPLS control plane is being considered to control multiplexing at an even finer granularity than that of the STS-1, the contents and structure of the STS-1 signal is briefly reviewed. The smallest granularity signal that we will be dealing with within a SONET STS-1 signal 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 identifies payload type), VT level fault management, performance monitoring, and signal identification (via the VT path trace J2). 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 (switch, multiplexer, terminal) is an important piece of network capability information that should be distributed via a route protocol while being able to identify which VT we are referring to is important in label distribution. Similar to section 2.1 we can define a Link SONET Multiplex Capability to be advertised by the routing protocol. The levels are as follows: STS-1, VT Group, VT6, VT3, VT2 and VT1.5. A set of flags (6 bits) can be used to indicate whether a particular level of signal/switching/multiplexing is supported. For example assuming the higher order bits are unused then the flag 00110001 would be used to indicate that STS-1, VT Group, and VT1.5 multiplexing is supported. Note that some combinations do not make sense, i.e., for any of the VTs to be supported VT Group and STS-1 multiplexing capabilities must be supported. In reference [9] and in [2] a numbering scheme was given to identify a particular signal within a SDH multiplex, we give a similar scheme here for SONET. In [9] a triple (K, L, M) where K denotes the TUG-3 number, L the TUG-2 number, and M the TU-1 number was used. For SONET we can use a similar triple (P, Q, R) where P denotes the STS- 1 number, Q denotes the VT Group number and R the VTx number. Note that P runs from 1 to N for an STS-N signal, Q runs from 1 to 7, and Mannie, E., Bernstein, G. [Page 6] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 that R is dependent on the type of virtual tributary (1, 1-2, 1-3, 1-4) for VT6 through VT1.5 respectively. When determining the final encoding of a SONET signal for label distribution (signaling) it is important to remember that these smaller granularity signals are frequently set up in batches. , For example, set me up 5 DS1s from this point to that, and it is desired that they run over the same SONET line (customers may be performing their own inverse multiplexing on these). 3.1 Link SDH Concatenation (LS-C) TLV: The Link SDH Concatenation TLV describes the SDH concatenation capabilities on that link. SDH defines two types of concatenation, the contiguous concatenation and the virtual concatenation. The first one is the concatenation of contiguous signals in the multiplex, and the second one is the concatenation of signals that are not contiguous. Moreover, concatenation is only defined for AU- 4s and TU-2s. The AU-4 virtual concatenation is FFS in [9]. Both types are defined for TU-2. TU-2s may be either concatenated contiguously in the higher order VC-3, or virtually in the higher order VC-4. 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 represented in the following. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Mannie, E., Bernstein, G. [Page 7] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 The Max AU-4s Contiguous field gives the maximum number of AU-4s that can be concatenated in one block on that 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 that 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 that 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. All possible limitations are hard to represent. That why we propose also an alternate way of representing the concatenation capabilities by listing explicitly all types of supported concatenations. 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' factor of the 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mannie, E., Bernstein, G. [Page 8] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 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 it is send, and must be ignored when it is received. If concatenation is not supported at all on a link, this TLV must not be sent. 3.2 Concatenation of SONET signals Reference [10] 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 route protocol for use in general LSP route selection. Currently there are three types of higher order concatenation types in SONET: standard concatenation, virtual concatenation and arbitrary concatenation. Standard SONET concatenated signals are STS-3c, STS-12c, STS-48c and STS-192c. Virtual concatenated signals are described in reference [10] and are denoted by STS-1-Xv where X is an integer. Note that in [10] and updates to [11] that in virtual concatenation the constituent STS-1 are transported individually across a SONET network and "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 Mannie, E., Bernstein, G. [Page 9] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 these two systems. A system supporting arbitrary concatenation would by definition support standard concatenation. Virtual concatenation 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 concatenated signal permitted. Hence for higher order concatenation we have three types of concatenation: standard, arbitrary and virtual. And we have the minimum granularity and maximum number of signals concatenated, i.e. max(N) for STS-Nc on this line. Hence an encoding similar to that of section 3.1 is applicable. Similar to virtual concatenation of STS-1, reference [10] defines virtual concatenation for virtual tributaries. Only virtual concatenation of VT1.5 is currently being considered. To make matters even simpler there is no standard (or contiguous) concatenation or arbitrary concatenation being considered for virtual tributaries. Hence, if VT1.5s are supported on an interface then we will want an flag to indicate whether or not virtual concatenation is supported and the minimum and maximum sizing of that concatenation. 4. Link SDH Bundle Size (LS-BS) TLV: The Link SDH Bundle Size TLV gives the number of identical components in a bundled link. Each component can be either a fiber or a wavelength. A mix of the two can be used if and only if they have the same TE characteristics from the SDH point of view. If a link is not bundled, this TLV cannot be used. 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 coded on 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 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 Bundle Size TLV. Mannie, E., Bernstein, G. [Page 10] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 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. 400 SDH STM-64 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. 5.1 Overview of Bandwidth Status Reporting in SONET and SDH There is a trade off to be reached concerning the amount of detail in the bandwidth resource information to be reported via a link state routing protocol, the frequency or conditions under which this information 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 must be placed. SDH has still more options and constraints hence it is not yet clear to one of the authors the best way to advertise bandwidth resource availability/usage in SONET/SDH. However, due to the multiplexed nature of the signals reporting of bandwidth particular to signal types rather than as a single aggregate bit rate is highly desirable. 5.2 Link SDH Allocation (LS-A) TLV: The Link SDH Allocation TLV is used to advertise a list of signals that have been allocated in the SDH multiplex of a link. The bandwidth used by these signals is allocated to some LSPs and 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 [2] (without the payload type extension). There is no need to advertise Mannie, E., Bernstein, G. [Page 11] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 MPLS labels in routing protocols. We refer to these labels here since their structure and coding as proposed in [2] reflect directly ("by coincidence") the signals that we want 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 described hereafter. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fiber Identifier | Wavelength Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Label Value List | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OSPF Link SDH 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 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-LSR that advertises the LSA/LSP. If the link is not a bundle, the SDH-LSR allocates a value such as 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 as defined in [2] on 32 bits (the S branch is coded on two octets to represent signals higher than STM-256). One single TLV cannot span two link components. If nothing is allocated, no TLV is advertised. A signal is allocated in the SDH multiplex of a link when an SDH-LSP is established through that link using that signal. A signal is Mannie, E., Bernstein, G. [Page 12] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 released in the multiplex of a link when the corresponding SDH-LSP is released. When a signal is allocated, the lower order signals that could be part of it are not advertised. A signal is a whole and its internal structure is unknown to the LSRs at each end of the link. If the signal is further channelized, it is under the responsibility of the node that initiated the corresponding SDH-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 needs to be aware of that channelization. Indeed, no LSR at all in the same routing domain need to be aware of that and nothing is advertised. However, an SDH-LSP could be advertised in a routing domain as a virtual link, i.e. a Forwarding Adjacency (FA) as defined in [5]. 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 structuration 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 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 the same link, before sending an LSA/LSP. Such behavior is however out of the scope of this document. Note that information about SDH concatenation of signals 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. 6. Grouping of contiguous allocated signals: In the worst case, if each lower order signal is advertised independently, a maximum of N*84 VC-11s signals are advertised per channelized STM-N link. Multiplied by the total number of links in the topology, this could be huge to advertise and to maintain in a Mannie, E., Bernstein, G. [Page 13] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 routing database. To help solving this issue, contiguous allocated signals could be grouped. Contiguous allocated signals that span a higher order signal, could be advertised by advertising only the higher order signal. The only important information to advertise here is the fact that these lower order signals are unavailable and what are their positions. We restrict the capability to group contiguous allocated signals in a single LSA/LSP, to the SDH-LSR that first originates the 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. 7. Link SDH Block Allocation (LS-BA) TLV: The Link SDH Block Allocation TLV is optional. It can be used to complement the Link SDH Allocation TLV. Indeed, it provides another way to represent allocated signals. It assumes that a large number of allocated signals are contiguous and can be represented by a starting signal and an ending signal. This TLV is made of a list of Block Entries, 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 hereafter. The starting, the ending signals and all intermediate signals are allocated. If the wavelength is not significant is must be set to zero. This TLV implies that an order is defined among the fibers and the wavelengths inside each fiber. It 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 Block Allocation TLV. 0 1 2 3 Mannie, E., Bernstein, G. [Page 14] draft-mannie-mpls-sdh-ospf-isis-00.txt July 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | List of Block Entries | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IS-IS Link SDH Block Allocation TLV. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Fiber Id. | Starting Wavelength Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Starting Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ending Fiber Id. | Ending Wavelength Id. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ending Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Block Entry. The Link SDH Allocation and Link SDH Block allocation can overlap and advertise signals in common. Each TLV must be advertised in a separate LSA/LSP. 8. Router SDH Interconnection Capability (RS-IC) TLV: This TLV describes the SDH interconnection capabilities of a particular SDH-LSR. The SDH multiplex allows transporting the same signal in 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 [2] section 10. SDH interconnection allows increasing the end-to-end connectivity capability when not all links have the same structure in a same routing domain (see [2]). 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 described hereafter. 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. Mannie, E., Bernstein, G. [Page 15] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 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 the 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 to 1 indicates that the corresponding interconnection is supported by the SDH-LSR, a flag to 0 indicates that it is not. The reserved field must be set to 0 when it is send, and must be ignored when it is received. 9. Router SDH-SONET Internetworking (RS-SI) TLV: This TLV describes a set of SDH-SONET internetworking capabilities. Internetworking happens 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. 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 is happening between a SONET routing domain and an SDH routing domain, and an inter-domain routing protocol is used (not in the scope of this section). 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 of this section. This routing domain could be divided or not in areas. We assume that an SDH-SONET-LSR (SS-LSR) advertising this RS-SI TLV could be an intra-area SS-LSR or an area border SS-LSR. 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 could advertise different internetworking capabilities. It is important for a source node to compute a source route through a border SS-LSR that has the right internetworking capabilities. Mannie, E., Bernstein, G. [Page 16] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 In the second case, a flat OSPF or IS-IS routing domain is used, mixing both SDH and SONET types of network. No inter-area exchange of information is taking place. This is the simplest case, 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 any 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 not 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. 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 | Mannie, E., Bernstein, G. [Page 17] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 when it is send, and ignored on when it is received. 9.1 Internetworking between STM-1 (SDH) and STS-1 (SONET): This internetworking happens in one direction 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. The VC-3 is then following the TUG-3/VC-4/AUG route. It happens in the other way in the opposite direction. |->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. Mannie, E., Bernstein, G. [Page 18] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 Using this capability, three independent DS-3 signals, each transported by a SONET STS-1 signal, can be multiplexed and transported in one single STM-1. Alternatively, the VC-3 could be transported via the AU-3/AUG route as described hereafter. 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 need 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). 9.2 Internetworking between STM-Mc (SDH) and STS-Nc (SONET) where N=3*M: Internetworking between STM-1 and STS-3c is simpler to implement since the two frames have the same structure. The standard SONET concatenation allows only the STS-N multiplexing where N is a multiple of 3. This helps with SDH internetworking. Internetworking between STM-Mc and STS-Nc, where N=3*M is also simple to implement. 9.3 Internetworking between STM-1 and STS-1 low order signals: Internetworking may also happen between SDH TUG-2, TU-11, TU-12 or TU-2 and respectively SONET VT Group, VT1.5, VT2 and VT6. Since the corresponding sub-signals have the same structure, the internetworking should be straightforward. 9.4 Overhead bytes differences in 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 case of STM-1/STS-1 internetworking the differences in path overhead bytes is such that the path must be terminated on each side Mannie, E., Bernstein, G. [Page 19] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 of the gateway. In case of STM-1/STS-3c internetworking the SDH and SONET paths do not need to be terminated at the gateway. 10. Updating the Routing Database: The maintenance of the routing database and the generation of LSA/LSPs can be complex. An SDH-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 that information must be flooded to all SDH-LSRs in the routing domain. This can result in generating a new LSA/LSP (for instance when the first signal is allocated on a link), updating an existing LSA/LSP or removing an existing LSA/LSP. Generating an LSA/LSP is a straightforward operation. However, an SDH-LSR should take care of not advertising too many small LSA/LSPs, or too many big LSA/LSPs. 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 didn't change are re-flooded and must be checked by each SDH-LSR in order to detect the missing signal that must be removed. 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 it is not advertised anymore by any LSA/LSP. This rule allows optimization between LS-A and LS-BA TLVs. Mannie, E., Bernstein, G. [Page 20] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 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. It results that we must group individual signals per LSA/LSP with adequate TLVs. OSPF and IS-IS implies two big problems, first each LSA/LSP must be refreshed periodically to avoid age timeout and removing. 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 routing is a protocol able to maintain a dynamic database with add and remove operations per list of database entries. 11. Size of routing 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 Mannie, E., Bernstein, G. [Page 21] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 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). 12. Security Considerations Security considerations are not discussed in this version of the document. 13. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] E. Mannie, "MPLS for SDH Control", draft-mannie-mpls-sdh- control-00.txt. Work in progress]. [3] D. Katz, D. yeung, "Traffic Engineering Extensions to OSPF", draft-katz-yeung-ospf-traffic-01.txt. Work in progress. [4] H. Smith, T. Li, "ISIS Extensions for Traffic Engineering", draft-ietf-isis-traffic-00.txt. Work in progress. [5] K. Kompella, Y. Rekhter, D. Awduche, A. Hannan, G. Hjalmtysson, J. Lawrence, S. Okamoto, D. Basak, G. Bernstein, J. Drake, N. Margalit, E. Stern, "Extensions to IS-IS/OSPF and RSVP in support of MPL(ambda)S", draft-kompella-mpls-optical-00.txt. Work in progress. [6]Kireeti Kompella, Yakov Rekhter, Lou Berger, "Link Bundling in MPLS Traffic Engineering", draft-kompella-mpls-bundling-02.txt. Work in progress, July 2000. [7] R. Coltun, RFC 2370, "The OSPF Opaque LSA Option", July 1998. [8] Greg Bernstein, "Some Comments on the Use of MPLS Traffic Engineering for SONET/SDH Path Establishment", draft-bernstein- mpls-sonet-00.txt, March 2000. Mannie, E., Bernstein, G. [Page 22] draft-mannie-mpls-sdh-ospf-isis-00.txt July 2000 [9] ITU-T Recommendation G.707 "Network Node Interface for the Synchronous Digital Hierarchy" 1996. [10] N. Jones, C. Murton, "Extending PPP over SONET/SDH, with Virtual concatenation, high order and low order payloads", Internet Draft <draft-ietf-pppext-posvcholo-02.txt>, June 2000. [11] American National Standards Institute, "Synchronous Optical Network (SONET) - Payload Mappings" ANSI T1.105.02-1998. 14. Acknowledgments One of the authors would like to thank Paolo Casaschi, Pedro Falcao, Gzim Ocakoglu for their valuable help and comments on this work (names sorted by alphabetical order), and more particularly Jose Miguel Santos for his help on SDH-SONET internetworking issues. 15. Author's Addresses Eric Mannie GTS Network Services RDI Department, Core Network Technology Group Terhulpsesteenweg, 6A 1560 Hoeilaart Belgium Tel: +32-2-658.56.52 E-mail: eric.mannie@gtsgroup.com Greg Bernstein Ciena Corporation 10480 Ridgeview Court Cupertino, CA 94014 Phone: (408) 366-4713 Email: greg@ciena.com Mannie, E., Bernstein, G. [Page 23]