--- 1/draft-ietf-ccamp-sdhsonet-control-04.txt 2006-02-04 22:58:15.000000000 +0100 +++ 2/draft-ietf-ccamp-sdhsonet-control-05.txt 2006-02-04 22:58:15.000000000 +0100 @@ -1,112 +1,107 @@ Network Working Group G. Bernstein (Grotto Networking) Internet Draft E. Mannie (InterAir Link) Category: Informational V. Sharma (Metanoia, Inc.) E. Gray (Marconi Communications) -Expires March 30, 2005 September 2004 +Expires August 2005 February 2005 Framework for GMPLS-based Control of SDH/SONET Networks - + Status of this Memo This document is an Internet-Draft and is subject to all provisions - of section 3 of RFC 3667 [1]. By submitting this Internet-Draft, - each author represents that any applicable patent or other IPR - claims of which he or she is aware have been or will be disclosed, - and any of which he or she becomes aware of will be disclosed, in - accordance with RFC 3668 [2]. + of section 3 of RFC 3667 [1] and Section 6 of RFC 3668 [2]. + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of RFC 3668. 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 - GMPLS consists of a suite of protocol extensions to MPLS to make - these protocols more generally applicable, to include - for example - - control of non-packet based switching, and particularly, optical - switching. One area of prime consideration is to use Generalized - MPLS (GMPLS) protocols in upgrading the control plane of optical - transport networks. This document illustrates this process by - describing those extensions to GMPLS protocols that are directed - towards controlling SDH/SONET networks. SDH/SONET networks make - very good examples of this process since they possess a rich - multiplex structure, a variety of protection/restoration options, - are well defined, and are widely deployed. The document discusses - extensions to GMPLS routing protocols to disseminate information - needed in transport path computation and network operations, - together with the extensions to GMPLS label distribution protocols - needed for the provisioning of transport circuits. New capabilities - that an GMPLS control plane would bring to SDH/SONET networks, such - as new restoration methods and multi-layer circuit establishment, - are also discussed. - -Internet Draft Expires March 2005 Page 1 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 + Generalized MPLS (GMPLS) is a suite of protocol extensions to MPLS + (Multi-Protocol Label Switching) to make it generally applicable, to + include - for example - control of non packet-based switching, and + particularly, optical switching. One consideration is to use GMPLS + protocols to upgrade the control plane of optical transport networks. + This document illustrates this process by describing those extensions + to GMPLS protocols that are aimed at controlling Synchronous Digital + Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. + SDH/SONET networks make good examples of this process for a variety + of reasons. This document high-lights extensions to GMPLS-related + routing protocols to disseminate information needed in transport path + computation and network operations, together with (G)MPLS protocol + extensions required for the provisioning of transport circuits. New + capabilities that an GMPLS control plane would bring to SDH/SONET + networks, such as new restoration methods and multi-layer circuit + establishment, are also discussed. - 1. Introduction.................................................3 - 1.1. MPLS Overview..............................................3 - 1.2. SDH/SONET Overview.........................................4 + 1. Introduction ................................................3 + 1.1. MPLS Overview .............................................3 + 1.2. SDH/SONET Overview ........................................4 1.3. The Current State of Circuit Establishment in SDH/SONET - Networks...................................................7 - 1.3.1. Administrative Tasks...................................7 - 1.3.2. Manual Operations......................................7 - 1.3.3. Planning Tool Operation................................7 - 1.3.4. Circuit Provisioning...................................8 - 1.4. Centralized Approach versus Distributed Approach...........8 - 1.4.1. Topology Discovery and Resource Dissemination..........9 + Networks ..................................................7 + 1.3.1. Administrative Tasks ..................................7 + 1.3.2. Manual Operations .....................................7 + 1.3.3. Planning Tool Operation ...............................7 + 1.3.4. Circuit Provisioning ..................................8 + 1.4. Centralized Approach versus Distributed Approach ..........8 + 1.4.1. Topology Discovery and Resource Dissemination .........9 1.4.2. Path Computation (Route Determination).................9 1.4.3. Connection Establishment (Provisioning)...............10 - 1.5. Why SDH/SONET will not Disappear Tomorrow.................11 - 2. GMPLS Applied to SDH/SONET..................................12 - 2.1. Controlling the SDH/SONET Multiplex.......................12 - 2.2. SDH/SONET LSR and LSP Terminology.........................13 - 3. Decomposition of the GMPLS Circuit-Switching Problem Space..13 - 4. GMPLS Routing for SDH/SONET.................................14 - 4.1. Switching Capabilities....................................15 - 4.1.1. Switching Granularity.................................15 - 4.1.2. Signal Concatenation Capabilities.....................16 - 4.1.3. SDH/SONET Transparency................................17 - 4.2. Protection................................................18 - 4.3. Available Capacity Advertisement..........................21 - 4.4. Path Computation..........................................22 - 5. LSP Provisioning/Signaling for SDH/SONET....................22 + 1.5. Why SDH/SONET will not Disappear Tomorrow ................11 + 2. GMPLS Applied to SDH/SONET .................................12 + 2.1. Controlling the SDH/SONET Multiplex ......................12 + 2.2. SDH/SONET LSR and LSP Terminology ........................13 + 3. Decomposition of the GMPLS Circuit-Switching Problem Space .13 + 4. GMPLS Routing for SDH/SONET ................................14 + 4.1. Switching Capabilities ...................................15 + 4.1.1. Switching Granularity ................................15 + 4.1.2. Signal Concatenation Capabilities ....................16 + 4.1.3. SDH/SONET Transparency ...............................17 + 4.2. Protection ...............................................18 + 4.3. Available Capacity Advertisement .........................21 + 4.4. Path Computation .........................................22 + 5. LSP Provisioning/Signaling for SDH/SONET ...................22 5.1. What do we Label in SDH/SONET? Frames or Circuits?........23 - 5.2. Label Structure in SDH/SONET..............................24 - 5.3. Signaling Elements........................................24 - 6. Summary and Conclusions.....................................26 - 7. Security Considerations.....................................27 - 8. Acknowledgments.............................................27 - 9. Author's Addresses..........................................27 - 10. References..................................................28 - 10.1. Normative References....................................28 - 10.2. Informative References..................................28 - 11. Intellectual Property Statement.............................29 - 12. Disclaimer of Validity......................................30 - 13. Copyright Statement.........................................30 - 14. Acknowledgement..............................................30 - -Internet Draft Expires March 2005 Page 2 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 + 5.2. Label Structure in SDH/SONET .............................24 + 5.3. Signaling Elements .......................................24 + 6. Summary and Conclusions ....................................26 + 7. Security Considerations ....................................27 + 8. Acknowledgments ............................................27 + 9. Author's Addresses .........................................27 + 10. References .................................................28 + 10.1. Normative References ...................................28 + 10.2. Informative References .................................28 + 11. Intellectual Property Statement ............................29 + 12. Disclaimer .................................................30 + 13. Copyright Statement ........................................30 + 14. IANA Considerations .........................................30 + 15. Acronyms ....................................................30 + 16. Acknowledgement .............................................31 1. Introduction The CCAMP Working Group of the IETF has the goal of extending MPLS [3] protocols to support multiple network layers and new services. This extended MPLS, which was initially known as Multi-Protocol Lambda Switching, is now better referred to as Generalized MPLS (or GMPLS). The GMPLS effort is, in effect, extending IP/MPLS technology to @@ -138,31 +133,28 @@ 1.1. MPLS Overview A major advantage of the MPLS architecture [3] for use as a general network control plane is its clear separation between the forwarding (or data) plane, the signaling (or connection control) plane, and the routing (or topology discovery/resource status) plane. This allows the work on MPLS extensions to focus on the forwarding and signaling planes, while allowing well-known IP routing protocols to be reused in the routing plane. This clear separation also allows - for MPLS to be used to control networks that do not have a packet- - based forwarding plane. + for MPLS to be used to control networks that do not have a + packet-based forwarding plane. An MPLS network consists of MPLS nodes called Label Switch Routers (LSRs) connected via circuits called Label Switched Paths (LSPs). An LSP is unidirectional and could be of several different types such as point-to-point, point-to-multipoint, and multipoint-to-point. -Internet Draft Expires March 2005 Page 3 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - Border LSRs in an MPLS network act either as ingress or egress LSRs depending on the direction of the traffic being forwarded. Each LSP is associated with a Fowarding Equivalence Class (FEC), which may be thought of as a set of packets that receive identical forwarding treatment at an LSR. The simplest example of an FEC might be the set of destination addresses lying in a given address range. All packets that have a destination address lying within this address range are forwarded identically at each LSR configured with that FEC. @@ -201,39 +193,36 @@ There are currently two different multiplexing technologies in use in optical networks: wavelength division multiplexing (WDM) and time division multiplexing (TDM). This work focuses on TDM technology. SDH and SONET are two TDM standards widely used by operators to transport and multiplex different tributary signals over optical links, thus creating a multiplexing structure, which we call the SDH/SONET multiplex. -Internet Draft Expires March 2005 Page 4 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - ITU-T (G.707) [4] includes both the European ETSI SDH hierarchy and the USA ANSI SONET hierarchy [5]. The ETSI SDH and SONET standards regarding frame structures and higher-order multiplexing are the same. There are some regional differences in terminology, on the use of some overhead bytes, and lower-order multiplexing. Interworking between the two lower-order hierarchies is possible using gateways. The fundamental signal in SDH is the STM-1 that operates at a rate of about 155 Mbps, while the fundamental signal in SONET is the STS- 1 that operates at a rate of about 51 Mbps. These two signals are made of contiguous frames that consist of transport overhead (header) and payload. To solve synchronization issues, the actual data is not transported directly in the payload but rather in another internal frame that is allowed to float over two successive SDH/SONET payloads. This internal frame is named a Virtual Container - (VC) in SDH and a Synchronous Payload Envelope (SPE) in SONET. + (VC) in SDH and a SONET Payload Envelope (SPE) in SONET. The SDH/SONET architecture identifies three different layers, each of which corresponds to one level of communication between SDH/SONET equipment. These are, starting with the lowest, the regenerator section/section layer, the multiplex section/line layer, and (at the top) the path layer. Each of these layers in turn has its own overhead (header). The transport overhead of a SDH/SONET frame is mainly sub-divided in two parts that contain the regenerator section/section overhead and the multiplex section/line overhead. In addition, a pointer (in the form of the H1, H2 and H3 bytes) @@ -257,23 +246,20 @@ does not fill a time slot completely, and the mapping rules define precisely how to fill it. What is important for the GMPLS-based control of SDH/SONET circuits is to identify the elements that can be switched from an input multiplex on one interface to an output multiplex on another interface. The only elements that can be switched are those that can be re-aligned via a pointer, i.e. a VC-x in the case of SDH and a SPE in the case of SONET. -Internet Draft Expires March 2005 Page 5 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - xN x1 STM-N<----AUG<----AU-4<--VC4<------------------------------C-4 E4 ^ ^ Ix3 Ix3 I I x1 I -----TUG-3<----TU-3<---VC-3<---I I ^ C-3 DS3/E3 STM-0<------------AU-3<---VC-3<-- I ---------------------I ^ I Ix7 Ix7 @@ -309,23 +295,20 @@ byte interleaving. The VCs/SPEs in the N interleaved frames are independent and float according to their own clocking. To transport tributary signals in excess of the basic STM-1/STS-1 signal rates, the VCs/SPEs can be concatenated, i.e., glued together. In this case their relationship with respect to each other is fixed in time and hence this relieves, when possible, an end system of any inverse multiplexing bonding processes. Different types of concatenations are defined in SDH/SONET. -Internet Draft Expires March 2005 Page 6 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - For example, standard SONET concatenation allows the concatenation of M x STS-1 signals within an STS-N signal with M <= N, and M = 3, 12, 48, 192,...). The SPEs of these M x STS-1s can be concatenated to form an STS-Mc. The STS-Mc notation is short hand for describing an STS-M signal whose SPEs have been concatenated. 1.3. The Current State of Circuit Establishment in SDH/SONET Networks In present day SDH and SONET networks, the networks are primarily statically configured. When a client of an operator requests a @@ -362,23 +345,20 @@ This first-time connection time is frequently accounted for in the overall establishment time. 1.3.3. Planning Tool Operation Another portion of the time is consumed by planning tools that run simulations using heuristic algorithms to find an optimized placement for the required circuits. These planning tools can require a significant running time, sometimes on the order of days. -Internet Draft Expires March 2005 Page 7 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - These simulations are, in general, executed for a set of demands for circuits, i.e., a batch mode, to improve the optimality of network resource usage and other parameters. Today, we do not really have a means to reduce this simulation time. On the contrary, to support fast, on-line, circuit establishment, this phase may be invoked more frequently, i.e., we will not "batch up" as many connection requests before we plan out the corresponding circuits. This means that the network may need to be re-optimized periodically, implying that the signaling should support re-optimization with minimum impact to existing services. @@ -417,24 +397,20 @@ approach has its merits. The application of GMPLS to SDH/SONET networks does not preclude either model, although GMPLS is itself a distributed technology. The basic tradeoff between the centralized and distributed approaches is that of complexity of the network elements versus that of the network management system (NMS). Since adding functionality to existing SDH/SONET network elements may not be possible, a centralized approach may be needed in some cases. The main issue facing centralized control via an NMS is one of scalability. For - -Internet Draft Expires March 2005 Page 8 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - instance, this approach may be limited in the number of network elements that can be managed (e.g., one thousand). It is, therefore, quite common for operators to deploy several NMS in parallel at the Network Management Layer, each managing a different zone. In that case, however, a Service Management Layer must be built on the top of several individual NMS to take care of end-to-end on-demand services. On the other hand, in a complex and/or dense network, restoration could be faster with a distributed approach than with a centralized approach. @@ -442,21 +418,21 @@ are handled via the centralized and distributed approaches: 1.4.1. Topology Discovery and Resource Dissemination Currently an NMS maintains a consistent view of all the networking layers under its purview. This can include the physical topology, such as information about fibers and ducts. Since most of this information is entered manually, it remains error prone. A link state GMPLS routing protocol, on the other hand, could - perform automatic topology discovery and dissemination the topology + perform automatic topology discovery and disseminate the topology as well as resource status. This information would be available to all nodes in the network, and hence also the NMS. Hence one can look at a continuum of functionality between manually provisioned topology information (of which there will always be some) and fully automated discovery and dissemination as in a link state protocol. Note that, unlike the IP datagram case, a link state routing protocol applied to the SDH/SONET network does not have any service impacting implications. This is because in the SDH/SONET case, the circuit is source-routed (so there can be no loops), and no traffic is transmitted until a circuit has been established, and an @@ -474,23 +450,20 @@ diversity or new optimization algorithms can be introduced with a simple NMS software upgrade. On the other hand, updating switches with new path computation software is a more complicated task. In addition, many of the algorithms can be fairly computationally intensive and may be completely unsuitable for the embedded processing environment available on most switches. In restoration scenarios, the ability to perform a reasonably sophisticated level of path computation on the network element can be particularly useful for restoring traffic during major network faults. -Internet Draft Expires March 2005 Page 9 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - 1.4.3. Connection Establishment (Provisioning) The actual setting up of circuits, i.e., a coupled collection of cross connects across a network, can be done either via the NMS setting up individual cross connects or via a "soft permanent LSP" (SPLSP) type approach. In the SPLSP approach, the NMS may just kick off the connection at the "ingress" switch with GMPLS signaling setting up the connection from that point onward. Connection establishment is the trickiest part to distribute, however, since errors in the connection setup/tear down process are service @@ -512,40 +485,37 @@ Distributed load Bottleneck: #requests and actions to/from NMS Individual local routing Centralized routing decision, decision can be done per block of requests Routing scalable as for the Assumes a few big Internet administrative domains - Complex to change routing Very easy local upgrade (non- + Complex to change routing Very easy local upgrade (non protocol/algorithm intrusive) Requires enhanced routing Better consistency protocol (traffic engineering) Ideal for inter-domain Not inter-domain friendly Suitable for very dynamic For less dynamic demands demands (longer lived) Probably faster to restore, Probably slower to restore,but but more difficult to have could effect reliable reliable restoration. restoration. -Internet Draft Expires March 2005 Page 10 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - High scalability Limited scalability: #nodes, (hierarchical) links, circuits, messages Planning (optimization) Planning is a background harder to achieve centralized activity Easier future integration with other control plane layers @@ -584,44 +554,40 @@ fairly fine granularity and that provides a very cheap and simple physical separation of the transported traffic between circuits, i.e., QoS. Moreover, even IP datagrams cannot be transported directly over a wavelength. A framing or encapsulation is always required to delimit IP datagrams. The Total Length field of an IP header cannot be trusted to find the start of a new datagram, since it could be corrupted and would result in a loss of synchronization. The typical framing used today for IP over DWDM is defined in RFC1619/RFC2615 and known as POS (Packet Over SDH/SONET), i.e., IP over PPP (in HDLC-like format) over SDH/SONET. SDH and SONET are - -Internet Draft Expires March 2005 Page 11 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - actually efficient encapsulations for IP. For instance, with an average IP datagram length of 350 octets, an IP over GBE encapsulation using an 8B/10B encoding results in 28% overhead, an IP/ATM/SDH encapsulation results in 22% overhead and an IP/PPP/SDH encapsulation results in only 6% overhead. Any encapsulation of IP over WDM should, in the data plane, at least provide error monitoring capabilities (to detect signal degradation); error correction capabilities, such as FEC (Forward Error Correction) that are particularly needed for ultra long haul transmission; sufficient timing information, to allow robust synchronization (that is, to detect the beginning of a packet). In the case where associated signaling is used (that is the control and data plane topologies are congruent) the encapsulation should also provide the capacity to transport signaling, routing and management messages, in order to control the optical switches. Rather SDH and SONET cover all these aspects natively, except FEC, which tends to be supported in a proprietary way. (We note, however, that associated signaling is not a requirement for the GMPLS-based - control of SDH/SONET networks. Rather, it is just one option. Non- + control of SDH/SONET networks. Rather, it is just one option. Non associated signaling, as would happen with an out-of-band control plane network is another equally valid option.) Since IP encapsulated in SDH/SONET is efficient and widely used, the only real difference between an IP over WDM network and an IP over SDH over WDM network is the layers at which the switching or forwarding can take place. In the first case, it can take place at the IP and optical layers. In the second case, it can take place at the IP, SDH/SONET, and optical layers. @@ -639,23 +605,20 @@ Controlling the SDH/SONET multiplex implies deciding which of the different switchable components of the SDH/SONET multiplex do we wish to control using GMPLS. Essentially, every SDH/SONET element that is referenced by a pointer can be switched. These component signals are the VC-4, VC-3, VC-2, VC-12 and VC-11 in the SDH case; and the VT and STS SPEs in the SONET case. The SPEs in SONET do not have individual names, although they can be referred to simply as VT-N SPEs. We will refer to them by identifying the structure that contains them, namely STS-1, VT-6, VT-3, VT-2 and VT-1.5. -Internet Draft Expires March 2005 Page 12 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - The STS-1 SPE corresponds to a VC-3, a VT-6 SPE corresponds to a VC- 2, a VT-2 SPE corresponds to a VC-12, and a VT-1.5 SPE corresponds to a VC-11. The SONET VT-3 SPE has no correspondence in SDH, however SDH's VC-4 corresponds to SONET's STS-3c SPE. In addition, it is possible to concatenate some of the structures that contain these elements to build larger elements. For instance, SDH allows the concatenation of X contiguous AU-4s to build a VC-4- Xc and of m contiguous TU-2s to build a VC-2-mc. In that case, a VC- 4-Xc or a VC-2-mc can be switched and controlled by GMPLS. SDH also @@ -667,23 +630,23 @@ Let a SDH or SONET Terminal Multiplexer (TM), Add-Drop Multiplexer (ADM) or cross-connect (i.e. a switch) be called an SDH/SONET LSR. A SDH/SONET path or circuit between two SDH/SONET LSRs now becomes a GMPLS LSP. An SDH/SONET LSP is a logical connection between the point at which a tributary signal (client layer) is adapted into its virtual container, and the point at which it is extracted from its virtual container. To establish such an LSP, a signaling protocol is required to configure the input interface, switch fabric, and output interface - of each SDH/SONET LSR along the path. An SDH/SONET LSP can be point- - to-point or point-to-multipoint, but not multipoint-to-point, since - no merging is possible with SDH/SONET signals. + of each SDH/SONET LSR along the path. An SDH/SONET LSP can be + point-to-point or point-to-multipoint, but not multipoint-to-point, + since no merging is possible with SDH/SONET signals. To facilitate the signaling and setup of SDH/SONET circuits, an SDH/SONET LSR must, therefore, identify each possible signal individually per interface, since each signal corresponds to a potential LSP that can be established through the SDH/SONET LSR. It turns out, however, that not all SDH signals correspond to an LSP and therefore not all of them need be identified. In fact, only those signals that can be switched need identification. 3. Decomposition of the GMPLS Circuit-Switching Problem Space @@ -694,24 +657,20 @@ applied to the optical switching problem space. (i) Information needed to compute paths must be made globally available throughout the network. Since this is done via the link state routing protocol, any information of this nature must either be in the existing link state advertisements (LSAs) or the LSAs must be supplemented to convey this information. For example, if it is desirable to offer different levels of service in a network based on whether a circuit is routed over SDH/SONET lines that are ring protected versus being routed over those that are not ring protected - -Internet Draft Expires March 2005 Page 13 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - (differentiation based on reliability), the type of protection on a SDH/SONET line would be an important topological parameter that would have to be distributed via the link state routing protocol. (ii) Information that is only needed between two "adjacent" switches for the purposes of connection establishment is appropriate for distribution via one of the label distribution protocols. In fact, this information can be thought of as the "virtual" label. For example, in SONET networks, when distributing information to switches concerning an end-to-end STS-1 path traversing a network, @@ -750,24 +709,20 @@ through a network is important to distribute via the routing protocol. In the TDM case, this information includes, but is not limited to: the available capacity of the network links, the switching and termination capabilities of the nodes and interfaces, and the protection properties of the link. This is what is being proposed in the GMPLS extensions to IP routing protocols [12], [13], [14]. When applying routing to circuit switched networks it is useful to compare and contrast this situation with the datagram routing case - -Internet Draft Expires March 2005 Page 14 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - [15]. In the case of routing datagrams, all routes on all nodes must be calculated exactly the same to avoid loops and "black holes". In circuit switching, this is not the case since routes are established per circuit and are fixed for that circuit. Hence, unlike the datagram case, routing is not service impacting in the circuit switched case. This is helpful, because, to accommodate the optical layer, routing protocols need to be supplemented with new information, much more than the datagram case. This information is also likely to be used in different ways for implementing different user services. Due to the increase in information transferred in @@ -804,24 +759,20 @@ Table 2. SDH/SONET switched signal groupings. Signal Type SDH SONET Lower Order VC-11, VC-12, VC-2 VT-1.5 SPE, VT-2 SPE, VT-3 SPE, VT-6 SPE Higher VC-3, VC-4 STS-1 SPE, STS-3c SPE Order - -Internet Draft Expires March 2005 Page 15 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - Manufacturers today differ in the types of switching capabilities their systems support. Many manufacturers today switch signals starting at VC-4 for SDH or STS-1 for SONET (i.e. the basic frame) and above (see Section 5.1.2 on concatenation), but they do not switch lower order signals. Some of them only allow the switching of entire aggregates (concatenated or not) of signals such as 16 VC-4s, i.e. a complete STM-16, and nothing finer. Some go down to the VC-3 level for SDH. Finally, some offer highly integrated switches that switch at the VC-3/STS-1 level down to lower order signals such as VC-12s. In order to cover the needs of all manufacturers and @@ -860,45 +811,42 @@ (where the rest of the signal gets put in terms of STS-1 slot numbers) leads to the requirement for re-grooming (due to bandwidth fragmentation). Due to these disadvantages some SONET framer manufacturers now support "flexible" or arbitrary concatenation, i.e., no restrictions on the size of an STS-Mc (as long as M <= N) and no constraints on the STS-1 timeslots used to convey it, i.e., the signals can use any combination of available time slots. -Internet Draft Expires March 2005 Page 16 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - Standard and flexible concatenations are network services, while virtual concatenation is a SDH/SONET end-system service approved by the Committee T1 of ANSI [5] and the ITU-T [4]. The essence of this service is to have SDH/SONET end systems "glue" together the VCs or SPEs of separate signals rather than requiring that the signals be carried through the network as a single unit. In one example of virtual concatenation, two end systems supporting this feature could essentially "inverse multiplex" two STS-1s into a STS-1-2v for the efficient transport of 100 Mbps Ethernet traffic. Note that this inverse multiplexing process (or virtual concatenation) can be significantly easier to implement with SDH/SONET than packet switched circuits, because ensuring that timing and in-order frame delivery is preserved may be simpler to establish using SDH/SONET rather than packet switched circuits, where more sophisticated techniques may be needed. Since virtual concatenation is provided by end systems, it is compatible with existing SDH/SONET networks. Virtual concatenation is defined for both higher order signals and low order signals. Table 3 shows the nomenclature and capacity for several lower-order - virtually concatenated signals contained within different higher- - order signals. + virtually concatenated signals contained within different + higher-order signals. Table 3 Capacity of Virtually Concatenated VTn-Xv (9/G.707) Carried In X Capacity In steps of VT1.5/ STS-1/VC-3 1 to 28 1600kbit/s to 1600kbit/s VC-11-Xv 44800kbit/s VT2/ STS-1/VC-3 1 to 21 2176kbit/s to 2176kbit/s @@ -914,24 +862,20 @@ The purposed of SDH/SONET is to carry its payload signals in a transparent manner. This can include some of the layers of SONET itself. For example, situations where the path overhead can never be touched, since it actually belongs to the client. This was another reason for not coding an explicit label in the SDH/SONET path overhead. It may be useful to transport, multiplex and/or switch lower layers of the SONET signal transparently. As mentioned in the introduction, SONET overhead is broken into - -Internet Draft Expires March 2005 Page 17 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - three layers: Section, Line and Path. Each of these layers is concerned with fault and performance monitoring. The Section overhead is primarily concerned with framing, while the Line overhead is primarily concerned with multiplexing and protection. To perform pipe multiplexing (that is, multiplexing of 50 Mbps or 150 Mbps chunks), a SONET network element should be line terminating. However, not all SONET multiplexers/switches perform SONET pointer adjustments on all the STS-1s contained within a higher order SONET signal passing through them. Alternatively, if they perform pointer adjustments, they do not terminate the line overhead. For example, a @@ -965,28 +909,26 @@ 4.2. Protection SONET and SDH networks offer a variety of protection options at both the SONET line (SDH multiplex section) and SDH/SONET path level [10], [11]. Standardized SONET line level protection techniques include: Linear 1+1 and linear 1:N automatic protection switching (APS) and both two-fiber and four-fiber bi-directional line switched rings (BLSRs). At the path layer, SONET offers uni-directional path switched ring protection. Likewise, standardized SDH multiplex section protection techniques include linear 1+1 and 1:N automatic p - protection switching and both two-fiber and four-fiber bi- - directional MS-SPRings (Multiplex Section-Shared Protection Rings). + protection switching and both two-fiber and four-fiber bi-directional + MS-SPRings (Multiplex Section-Shared Protection Rings). + At the path layer, SDH offers SNCP (sub-network connection protection) ring protection. -Internet Draft Expires March 2005 Page 18 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - Both ring and 1:N line protection also allow for "extra traffic" to be carried over the protection line when that line is not being used, i.e., when it is not carrying traffic for a failed working line. These protection methods are summarized in Table 5. It should be noted that these protection methods are completely separate from any GMPLS layer protection or restoration mechanisms. Table 5. Common SDH/SONET protection mechanisms. Protection Type Extra Comments @@ -1024,24 +966,20 @@ UPSR (uni- No Dedicated protection via directional alternative ring path. path switched Typically used in access ring) networks. It may be desirable to route some connections over lines that support protection of a given type, while others may be routed over unprotected lines, or as "extra traffic" over protection lines. Also, to assist in the configuration of these various protection methods it can be extremely valuable to advertise the link - -Internet Draft Expires March 2005 Page 19 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - protection attributes in the routing protocol, as is done in the current GMPLS routing protocols. For example, suppose that a 1:N protection group is being configured via two nodes. One must make sure that the lines are "numbered the same" with respect to both ends of the connection or else the APS (K1/K2 byte) protocol will not correctly operate. Table 6. Parameters defining protection mechanisms. Protection Comments @@ -1077,24 +1015,20 @@ line, Dedicated (1:1, 1+1)/Working Line, Enhanced (Ring) /Working Line, represents the other. There is also a potential implication for link bundling [16], [18] that is, for each link, the routing protocol could advertise whether that link is a working or protection link and possibly some parameters from Table 6. A possible drawback of this scheme is that the routing protocol would be burdened with advertising properties even for those protection links in the network that could not, in fact, be used for routing working traffic, e.g., dedicated - -Internet Draft Expires March 2005 Page 20 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - protection links. An alternative method would be to bundle the working and protection links together, and advertise the bundle instead. Now, for each bundled link, the protocol would have to advertise the amount of bandwidth available on its working links, as well as the amount of bandwidth available on those protection links within the bundle that were capable of carrying "extra traffic." This would reduce the amount of information to be advertised. An issue here would be to decide which types of working and protection links to bundle together. For instance, it might be preferable to bundle working links (and their corresponding protection links) that @@ -1132,48 +1066,44 @@ 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 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 flexible 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 - -Internet Draft Expires March 2005 Page 21 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - only standard concatenation is supported, then reporting gets trickier since there are constraints on where the STS-1s can 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 SDH/SONET. At present, the GMPLS routing protocol extensions define minimum and maximum values for available bandwidth, which allows a remote node to make some deductions about the amount of capacity available at a remote link and the types of signals it can accommodate. However, due to the multiplexed nature of the signals, reporting of bandwidth particular to signal types rather than as a single aggregate bit rate may be desirable. For details on why this may be the case, we refer the reader to ITU-T publications G.7715.1 [19] and to Chapter 12 of [20]. 4.4. Path Computation Although a link state routing protocol can be used to obtain network topology and resource information, this does not imply the use of an "open shortest path first" route [9]. The path must be open in the sense that the links must be capable of supporting the desired - signal type and that capacity must be available to carry the - signal. Other constraints may include hop count, total delay - (mostly propagation), and underlying protection. In addition, it may - be desirable to route traffic in order to optimize overall network + signal type and that capacity must be available to carry the signal. + Other constraints may include hop count, total delay (mostly + propagation), and underlying protection. In addition, it may be + desirable to route traffic in order to optimize overall network capacity, or reliability, or some combination of the two. Dikstra's algorithm computes the shortest path with respect to link weights for a single connection at a time. This can be much different than the paths that would be selected in response to a request to set up a batch of connections between a set of endpoints in order to optimize network link utilization. One can think of this along the lines of global or local optimization of the network in time. Due to the complexity of some of the connection routing algorithms (high dimensionality, non-linear integer programming problems) and @@ -1187,28 +1117,24 @@ routing algorithm. 5. LSP Provisioning/Signaling for SDH/SONET Traditionally, end-to-end circuit connections in SDH/SONET networks have been set up via network management systems (NMSs), which issue commands (usually under the control of a human operator) to the various network elements involved in the circuit, via an equipment vendor's element management system (EMS). Very little multi-vendor interoperability has been achieved via management systems. Hence, - -Internet Draft Expires March 2005 Page 22 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - end-to-end circuits in a multi-vendor environment typically require the use of multiple management systems and the infamous configuration via "yellow sticky notes". As discussed in Section 3, a common - signaling protocol, such as RSVP with TE extensions or CR- LDP + signaling protocol - such as RSVP with TE extensions or CR-LDP - appropriately extended for circuit switching applications, could therefore help to solve these interoperability problems. In this section, we examine the various components involved in the automated provisioning of SDH/SONET LSPs. 5.1. What do we Label in SDH/SONET? Frames or Circuits? GMPLS was initially introduced to control asynchronous technologies like IP, where a label was attached to each individual block of data, such as an IP packet or a Frame Relay frame. SONET and SDH, @@ -1224,44 +1150,41 @@ It will be seen in what follows that each SONET or SDH "frame" need not have its own label, nor is it necessary to switch frames individually. Rather, the unit that is switched is a "flow" comprised of a continuous sequence of time slots that appear at a given position in a frame. That is, we switch an individual SONET or SDH signal, and a label associated with each given signal. For instance, the payload of an SDH STM-1 frame does not fully contain a complete unit of user data. In fact, the user data is contained in a virtual container (VC) that is allowed to float over - two contiguous frames for synchronization purposes. The H1-H2-H3 Au- - n pointer bytes in the SDH overhead indicates the beginning of the + two contiguous frames for synchronization purposes. The H1-H2-H3 + Au-n pointer bytes in the SDH overhead indicates the beginning of the VC in the payload. Thus, frames are now inter-related, since each consecutive pair may share a common virtual container. From the point of view of GMPLS, therefore, it is not the successive frames that are treated independently or labeled, but rather the entire user signal. An identical argument applies to SONET. Observe also that the GMPLS signaling used to control the SDH/SONET multiplex must honor its hierarchy. In other words, the SDH/SONET layer should not be viewed as homogeneous and flat, because this would limit the scope of the services that SDH/SONET can provide. Instead, GMPLS tunnels should be used to dynamically and hierarchically control the SDH/SONET multiplex. For example, one unstructured VC-4 LSP may be established between two nodes, and later lower order LSPs (e.g. VC-12) may be created within that higher order LSP. This VC-4 LSP can, in fact, be established between two non-adjacent internal nodes in an SDH network, and later advertised by a routing protocol as a new (virtual) link called a Forwarding Adjacency (FA) [17]. -Internet Draft Expires March 2005 Page 23 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - A SDH/SONET-LSR will have to identify each possible signal individually per interface to fulfill the GMPLS operations. In order to stay transparent the LSR obviously should not touch the SDH/SONET overheads; this is why an explicit label is not encoded in the SDH/SONET overheads. Rather, a label is associated with each individual signal. This approach is similar to the one considered for lambda switching, except that it is more complex, since SONET and SDH define a richer multiplexing structure. Therefore a label is associated with each signal, and is locally unique for each signal at each interface. This signal could, and will most probably, @@ -1300,24 +1223,20 @@ multiplex-based labeling. This is the idea that was incorporated in the GMPLS signaling specifications for SDH/SONET [18]. 5.3. Signaling Elements In the preceding sections, we defined the meaning of a SDH/SONET label and specified its structure. A question that arises naturally at this point is the following. In an LSP or connection setup request, how do we specify the signal for which we want to establish a path (and for which we desire a label)? - -Internet Draft Expires March 2005 Page 24 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - Clearly, information that is required to completely specify the desired signal and its characteristics must be transferred via the label distribution protocol, so that the switches along the path can be configured to correctly handle and switch the signal. This information is specified in three parts [18], each of which refers to a different network layer. 1. GENERALIZED_LABEL REQUEST (as in [6], [7]), which contains three parts: LSP Encoding Type, Switching Type, and G-PID. @@ -1356,24 +1275,20 @@ a virtually concatenated signal. - Third, some transparency (by using the Transparency field) can be optionally specified when requesting a frame as signal rather than an SPE or VC based signal. - Fourth, a multiplication (by using the Multiplier field) can be optionally applied either directly on the Elementary Signal, or on the contiguously concatenated signal obtained from the first phase, or on the virtually concatenated signal - -Internet Draft Expires March 2005 Page 25 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - obtained from the second phase, or on these signals combined with some transparency. Transparency indicates precisely which fields in these overheads must be delivered unmodified at the other end of the LSP. An ingress LSR requesting transparency will pass these overhead fields that must be delivered to the egress LSR without any change. From the ingress and egress LSRs point of views, these fields must be seen as unmodified. @@ -1411,36 +1326,36 @@ TDM equipment, and the requirement to learn about the protection capabilities of underlying links, and how these influence the available capacity advertisement in TDM networks. We focused briefly on path computation methods, pointing out that these were not subject to standardization. We then examined optical path provisioning or signaling, considering the issue of what constitutes an appropriate label for TDM circuits and how this label should be structured, and we focused on the importance of hierarchical label allocation in a TDM network. Finally, we reviewed - -Internet Draft Expires March 2005 Page 26 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - the signaling elements involved when setting up an TDM circuit, focusing on the nature of the LSP, the type of payload it carries, and the characteristics of the links that the LSP wishes to use at each hop along its path for achieving a certain reliability. 7. Security Considerations This document describes the framework for GMPLS extensions for use in SDH/SONET control. As such, it introduces no new security issues with respect to GMPLS specifications. GMPLS protocol specifications should identify and address security issues specific to protocol. + Among the considerations that should be addressed by GMPLS protocol + specifications, are any security vulnerabilities that are introduced + by specific GMPLS extensions added in each specification. + 8. Acknowledgments We acknowledge all the participants of the MPLS and CCAMP WGs, whose constant enquiry about GMPLS issues in TDM networks motivated the writing of this document, and whose questions helped shape its contents. Also, thanks to Kireeti Kompella for his careful reading of the last version of this document, and for his helpful comments and feedback, and to Dimitri Papadimitriou for his review on behalf of the Routing Area Directorate, which provided many useful inputs to help update the document to conform to the standards evolutions @@ -1462,23 +1377,20 @@ Metanoia, Inc. 888 Villa Street, Suite 200B Mountain View, CA 94041 Phone: +1 408 530 8313 Email: v.sharma@ieee.org Eric Gray Marconi Communications E-mail: Eric.Gray@Marconi.com -Internet Draft Expires March 2005 Page 27 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - 10. References 10.1. Normative References [1] Bradner, S., "IETF Rights in Contributions" BCP 78, RFC 3667, February, 2004. [2] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February, 2004. @@ -1512,99 +1424,134 @@ Mag., Vol. 40, Issue 10, October 2000. [10] ANSI T1.105.01-1995, Synchronous Optical Network (SONET) Automatic Protection Switching, American National Standards Institute. [11] G.841, Types and Characteristics of SDH Network Protection Architectures, ITU-T, July 1995. [12] Kompella, K., et al, "Routing Extensions in Support of - Generalized MPLS," Internet Draft, Work-in-Progress, draft- - ietf-ccamp-gmpls-routing-09.txt, October 2003. - -Internet Draft Expires March 2005 Page 28 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 + Generalized MPLS," Internet Draft, Work-in-Progress, + draft-ietf-ccamp-gmpls-routing-09.txt, October 2003. [13] Kompella, K., et al, "OSPF Extensions in Support of Generalized - MPLS," Internet Draft, Work-in-Progress, draft-ietf-ccamp- - ospf-extensions-12.txt, October 2003. + MPLS," Internet Draft, Work-in-Progress, + draft-ietf-ccamp-ospf-extensions-12.txt, October 2003. [14] Kompella, K., et al, "IS-IS Extensions in Support of - Generalized MPLS," Internet Draft, Work-in-Progress, draft- - ietf-isis-gmpls-extensions-16.txt, August 2002. + Generalized MPLS," Internet Draft, Work-in-Progress, + draft-ietf-isis-gmpls-extensions-16.txt, August 2002. [15] Bernstein, G., Sharma, V., Ong, L., "Inter-domain Optical - Routing, " OSA J. of Optical Networking, vol. 1, no. 2, pp. 80- - 92. + Routing, " OSA J. of Optical Networking, vol. 1, no. 2, pp. + 80-92. [16] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling in MPLS Traffic Engineering", Internet Draft, Work-in-Progress, draft-ietf-mpls-bundle-04.txt, July 2002. [17] Kompella, K., Rekhter, Y., "LSP Hierarchy with Generalized - MPLS-TE", Internet Draft, Work-in-Progress, draft-ietf-mpls- - lsp-hierarchy-08.txt, September 2002. + MPLS-TE", Internet Draft, Work-in-Progress, + draft-ietf-mpls-lsp-hierarchy-08.txt, February 2002. [18] Mannie, E. (Editor), "GMPLS Extensions for SONET and SDH - Control", Internet Draft, Work-in-Progress, draft-ietf-ccamp- - gmpls-sonet-sdh-08.txt, February 2003. + Control", Internet Draft, Work-in-Progress, + draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, February 2003. - [19] G.7715.1, ASON Routing Architecture and Requirements for Link- - State Protocols, International Telecommunications Union, + [19] G.7715.1, ASON Routing Architecture and Requirements for + Link-State Protocols, International Telecommunications Union, February 2004. [20] Bernstein, G., Rajagopalan, R., and Saha, D., "Optical Network - Control: Protocols, Architectures, and Standards," Addison- - Wesley, July 2003. + Control: Protocols, Architectures, and Standards," + Addison-Wesley, July 2003. 11. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed - to pertain to the implementation or use of the technology described - in this document or the extent to which any license under such - rights might or might not be available; nor does it represent that - it has made any independent effort to identify any such rights. - Information on the procedures with respect to rights in RFC - documents can be found in BCP 78 and BCP 79. + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. -Internet Draft Expires March 2005 Page 29 -Bernstein, et al GMPLS based Control of SDH/SONET September 2004 - The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. -12. Disclaimer of Validity +12. Disclaimer - This document and the information contained herein are provided on - an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE - REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, - EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT - THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR - ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A - PARTICULAR PURPOSE. + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 13. Copyright Statement - "Copyright (C) The Internet Society (2004). This document is + Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their - rights." + rights. -14. Acknowledgement +14. IANA Considerations + + There are no IANA considerations that apply to this document. + +15. Acronyms + + ANSI - American National Standards Institute + APS - Automatic Protection Switching + ATM - Asynchronous Transfer Mode + BLSR - Bi-directional Line Switch Ring + CPE - Customer Premise Equipment + DLCI - Data Link Connection Identifier + ETSI - European Telecommunication Standards Institute + FEC - Forwarding Equivalency Class + GMPLS - Generalized MPLS + IP - Internet Protocol + IS-IS - Intermediate System to Intermediate System (RP) + LDP - Label Distribution Protocol + LSP - Label Switched Path + LSR - Label Switching Router + MPLS - Multi-Protocol Label Switching + NMS - Network Management System + OSPF - Open Shortest Path First (RP) + PNNI - Private Network Node Interface + PPP - Point to Point Protocol + QoS - Quality of Service + RP - Routing Protocol + RSVP - ReSerVation Protocol + SDH - Synchronous Digital Hierarchy + SNMP - Simple Network Management Protocol + SONET - Synchronous Optical NETworking + SPE - SONET Payload Envelope + STM - Synchronous Transport Module (or Terminal Multiplexer) + STS - Synchronous Transport Signal + TDM - Time Division Multiplexer + TE - Traffic Engineering + TMN - Telecommunication Management Network + UPSR - Uni-directional Path Switch Ring + VC - Virtual Container (SDH) or Virtual Circuit + VCI - Virtual Circuit Identifier (ATM) + VPI - Virtual Path Identifier (ATM) + VT - Virtual Tributary + WDM - Wave-length Division Multiplexing + +16. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. - -Internet Draft Expires March 2005 Page 30