idnits 2.17.1 draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 24 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([GMPLS-SONET-SDH], [GMPLS-SONET-SDH-EXT], [GMPLS-SONET-SDH-RTG]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8197 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'GMPLS-SDH-SONET-RTG' is mentioned on line 117, but not defined == Unused Reference: 'GMPLS-SONET-SDH-CCV' is defined on line 365, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-06 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-04 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-05 == Outdated reference: A later version (-08) exists of draft-ietf-ccamp-gmpls-sonet-sdh-02 == Outdated reference: A later version (-03) exists of draft-ietf-ccamp-gmpls-sonet-sdh-extensions-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-gmpls-sonet-sdh-extensions (ref. 'GMPLS-SONET-SDH-EXT') -- No information found for draft-ietf-ccamp-gmpls-concatenation-conversion - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'GMPLS-SONET-SDH-CCV' == Outdated reference: A later version (-02) exists of draft-mannie-mpls-sdh-ospf-isis-01 -- Possible downref: Normative reference to a draft: ref. 'GMPLS-SONET-SDH-RTG' == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-00 Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group E. Mannie (Ebone) 3 Informational Draft D. Papadimitriou (Alcatel) 4 Expiration Date: May 2002 5 November 2001 7 GMPLS Interworking between Sonet and SDH 9 draft-papadim-ccamp-gmpls-sonet-sdh-interwork-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are 15 working documents of the Internet Engineering Task Force (IETF), 16 its areas, and its working groups. Note that other groups may 17 also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 To view the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow 27 Directory, see http://www.ietf.org/shadow.html. 29 Abstract 31 This document is a companion to the GMPLS extensions to control 32 SONET/SDH networks as defined in [GMPLS-SONET-SDH], [GMPLS-SONET- 33 SDH-EXT] and [GMPLS-SONET-SDH-RTG]. They define the SONET and SDH 34 technology specific information needed when using GMPLS signaling. 35 This informational memo details the GMPLS signalling and some 36 routing specific considerations to control the interworking 37 between SONET and SDH networks. It results from this, that 38 interworking issues from the control plane viewpoint are well 39 covered by the current definition of the Sonet/SDH extensions to 40 the GMPLS protocol suite. 42 1. Introduction 44 Generalized MPLS (GMPLS) [GMPLS-ARCH] extends MPLS from supporting 45 packet (Packet Switching Capable - PSC) interfaces and switching 46 to include support of four new classes of interfaces and 47 switching: Layer 2 Switch Capable (L2SC), Time-Division Multiplex 48 (TDM), Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC). 50 Informational Draft � Expires May 2002 1 51 A functional description of the extensions to MPLS signaling 52 needed to support these new classes of interfaces and switching is 53 provided in [GMPLS-SIG]. [GMPLS-RSVP] describes RSVP-TE specific 54 formats and mechanisms needed to support all four classes of 55 interfaces, and CR-LDP extensions can be found in [GMPLS-LDP]. 57 [GMPLS-SONET-SDH] and [GMPLS-SONET-SDH-EXT] present details that 58 are specific to SONET/SDH. Per [GMPLS-SIG], SONET/SDH specific 59 parameters are carried through the signaling protocol in traffic 60 parameter specific objects. 62 This informational memo describes GMPLS signaling and some routing 63 considerations to control interworking between SONET and SDH. 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 66 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 67 in this document are to be interpreted as described in [RFC2119]. 69 2. SONET/SDH Interworking 71 This section describes how SDH and SONET can interwork at the 72 transport plane level. SONET networks are based on STS-1 frames 73 while SDH networks are based on STM-1 frames. An STS-1 frame is 74 composed by a transport overhead (corresponding to the SDH RS and MS 75 overhead) and a SPE (corresponding to the SDH VC-3 plus two columns 76 of fixed stuff). There is no equivalent for an STS-1 frame in the 77 SDH standard, but an STS-1 frame would correspond to an SDH frame 78 build with a single AU-3. 80 Three major different ways of providing the interworking 81 capabilities are presented hereafter: 83 1. Interworking between VC-4 and STS-1 SPE 84 2. Interworking between VC-4-Nc and STS-(3*N)c SPE (SONET) 85 3. Interworking between VC-4 and STS-1 SPE lower order signals 87 Interworking between SDH and SONET may be needed for different 88 reasons. For instance, it may happen between North American and 89 European operators in order to provide connectivity between them. In 90 these cases, interworking occurs between a SONET routing domain and 91 an SDH routing domain, and requires an inter-domain routing protocol 92 for capability exchange between these domains (it is, therefore, not 93 in the scope of this document to specify the corresponding 94 extensions). 96 However, interworking may also be useful for a single operator 97 providing both SDH and SONET services in the same routing domain. In 98 this case, the routing domain may or may not be divided into areas. 99 We assume that a SDH/SONET gateway can be an intra-area node or an 100 area border node. 102 First consider the case where the domain is divided into areas. For 103 instance, if one OSPF area is SONET based, and the backbone area is 104 SDH based, different area border nodes between these two areas could 106 Informational Draft � Expires May 2002 2 107 advertise different interworking capabilities. For a source node to 108 be able to compute a source route, it is important that it be able 109 to compute a source route through a border node providing the 110 adequate interworking capabilities. 112 Next consider the case where there are no areas, and a flat OSPF or 113 IS-IS routing domain is used, mixing both SDH and SONET types of 114 network. No inter-area exchange of information needs to take place. 115 This is the simplest case where interworking considerations can be 116 applied without any additional routing considerations from the one 117 covered in [GMPLS-SDH-SONET-RTG]. 119 A node capable of acting as a SDH/SONET gateway should advertise its 120 particular interworking capabilities to every other node belonging 121 to the same routing domain. 123 In the scope of this memo, a SDH/SONET gateway node includes at 124 least one Sonet and one SDH interface. It is capable to terminate 125 both the Section/RS Overhead and Line/MS Overhead on Sonet/SDH 126 interface, respectively. Pointer processing follows the rules 127 defined in ITU-T G.707 and ANSI T1.105. 129 The SDH/SONET interworking scenarios supported in this specification 130 cover: 131 - Interworking between VC-4 and STS-1 SPE 132 - Interworking between VC-4-Nc and STS-(3*N)c SPE 133 - Interworking between VC-4 and STS-1 SPE lower order signals 135 Note: section 3.2 covers interworking between VC-4-Xc and STS-3c-Xc 136 Contiguous concatenation issues 138 2.1 Interworking between VC-4 and STS-1 SPE 140 In one direction, from STS-1 to STM-1 (interface level), this 141 interworking is accomplished by extracting the SPE of an STS-1, 142 transforming the SPE into a VC-3 via pointer processing and the 143 removal of two columns of fixed stuff bytes, and processing the VC-3 144 via the TU-3/TUG-3/VC-4/AUG route as shown below. In the other 145 direction, from STM-1 to STS-1, exactly the opposite occurs. 147 ->STM-1 148 | 149 |x1 150 | 151 ->VC4-->AU4-->AUG- 152 | 153 |x3 154 | 155 STS-1- ->TU3-->TUG3- 156 | | 157 | |x1 158 | | 159 -SPE--transf-->VC3- 161 Informational Draft � Expires May 2002 3 162 Figure: STS-1 to STM-1 mapping through TU-3. 164 Using this capability, for instance, three independent DS-3 signals, 165 each transported by a SONET STS-1 signal, can be multiplexed and 166 transported in one single STM-1 signal. 168 Alternatively, the VC-3 could be transported via the AU-3/AU-3 route 169 as described below. Again three independent DS-3 signals transported 170 over SONET can be transported over SDH. 172 ->AUG->STM-1 173 | 174 |x3 175 | 176 STS-1- -->AU3-- 177 | | 178 | |x1 179 | | 180 -SPE--transf-->VC3- 182 Figure: STS-1 to STM-1 mapping through VC-3/AU-3. 184 Note that if a single DS-3 has to be transported end-to-end, it can 185 imply on the SDH side that a whole VC-4 needs to be equipped to the 186 end, even if the two other VC-3 components are not used. Ideally, 187 the routing algorithm should know the details of both the SDH and 188 the SONET clouds in order to find the path that minimizes the number 189 of SDH VC-3s that will not be used (i.e. to minimize internal 190 fragmentation of VC-4s due to the interworking). 192 SDH networks support both VC-3 and VC-4, however SDH mainly uses VC- 193 4s. Therefore a SONET signal must be mainly demultiplexed, 194 transformed and remultiplexed within an SDH AUG via the TU-3/TUG- 195 3/VC-4/AU-4 route. 197 2.2 Interworking between VC-4-Nc and STS-(3*N)c SPE 199 Interworking between VC-4 and STS-3c SPE is simpler to implement 200 since the two frames have the same structure. In practice, a VC-4-Nc 201 will be mapped to an STS-(3*N)c and vice versa. 203 The standard SONET concatenation only allows STS-Nc multiplexing 204 where N is a multiple of 3. This helps with SDH interworking. 205 Likewise, interworking between VC-4-Nc and STS-(3*N)c is relatively 206 simple to implement. Note however than certain interworking issues 207 still remain due to overhead processing differences. 209 2.3 Interworking between VC-4 and STS-1 SPE Lower Order Signals 211 Interworking is also possible between the SDH TUG-2, TU-11, TU-12 or 212 TU-2 and respectively the SONET VT Group, VT1.5, VT2 and VT6. Since 213 the corresponding sub-signals have the same structure, this 214 interworking should be straightforward. Note however that a SONET 215 VT-3 (SPE) has no equivalent in the SDH world. 217 Informational Draft � Expires May 2002 4 218 3. Generalized MPLS Signalling 220 This document specifies the GMPLS interworking between an SDH cloud 221 and a SONET cloud through the use of gateways. A gateway is an node 222 that has to transform the transport plane, do some light translation 223 in the signaling and that may have to adapt some link state 224 advertisements. 226 IP addresses are considered here as unique in the whole network. We 227 assume hereafter that the same GMPLS profile is implemented on both 228 sides of each gateway and that GMPLS is used end-to-end. 229 Consequently, only a few technology specific fields need to be 230 translated in the GMPLS signaling when using such a gateway. 232 Note that there is no translation required for the labels since they 233 are purely local per interface. Consequently there is no label 234 interworking issue. 236 3.1 Signaling Aspects 238 To open an SDH or SONET circuit a signaling message is sent from the 239 source to the destination in an RSVP-TE Path or CR-LDP Label Request 240 message. This signaling message transports a Generalized Label 241 Request Object/TLV and a SONET/SDH Traffic Parameters Object/TLV. 243 The LSP Encoding Type included within the Generalized Label Request 244 indicates either SDH or SONET in our case. A gateway has to 245 translate this field from value SDH ITU-T G.707 (5) to value Sonet 246 ANSI T1.105 (6) and vice versa. 248 The SONET/SDH Traffic parameters contains multiple fields, some of 249 them may not be used. One of these fields is the Signal Type which 250 indicates the base type of signal being considered. The Signal Type 251 values are defined identically for both SDH and SONET to simplify 252 interworking issues. 254 For a basic request including an elementary Signal Type on which no 255 concatenation and no transparency is applied, no Signal Type 256 transformation is needed. Moreover, the Multiplier field doesn't 257 require any modification. 259 There is however one restriction, this document doesn't cover SONET 260 VT-3 interworking since it has no equivalent in SDH. Concatenation 261 and transparency are discussed in the next sub-sections. 263 3.2 Contiguous Concatenation 265 [GMPLS-SONET-SDH] and [GMPLS-SONET-SDH-EXT] define the following 266 optional flags for the Requested Contiguous Concatenation (RCC) 267 field: 269 Flag 1 (bit 1): Standard Contiguous Concatenation 270 Flag 2 (bit 2): Arbitrary Contiguous Concatenation 272 Informational Draft � Expires May 2002 5 273 If contiguous concatenation is requested in the Traffic Parameter 274 Object/TLV, this memo allows only the interworking between a VC-4- 275 Xc and an STS-3c-Xc using the Standard Contiguous Concatenation. 276 In this case, the Signal Type, RCC and NCC fields do not have to 277 be modified. The transport plane transformation is done as 278 explained in section 2.2. 280 All other cases of contiguous concatenations, in particular the 281 arbitrary one, are for further study. 283 3.3 Transparency 285 The Transparency field (defined as a vector of flag) indicates 286 within precisely which fields in these SONET/SDH overheads must be 287 delivered unmodified at the other end of the LSP. An ingress node 288 requesting transparency will pass these overhead fields that must be 289 delivered to the egress node without any change. From the ingress 290 and egress nodes point-of-views, these fields must be seen as 291 unmodified. 293 Transparency is not applied at the interfaces with the initiating 294 and terminating nodes, but is only applied between intermediate 295 nodes. Notice that Transparency is only applicable when frame types 296 of signal are used. 298 They are some difference in the overheads between SONET and SDH. 299 Detailed explanations concerning the mapping between the two is not 300 in the scope of this specification. The effect of these differences 301 on the Transparency field is left for further study. 303 3.4 Virtual Concatenation 305 This section will include in a further release the Virtual 306 Concatenation interworking issues. In particular when the ingress 307 (egress) node include an SDH VC capable interface and the egress 308 (ingress, respectively) a Sonet VC capable interface. 310 4. Interworking Rules 312 This section summarizes the interworking rules: 314 - LSP Encoding Type: value change from LSP Encoding Type value 5 to 315 6 (when flowing from SDH to Sonet) and from value 6 to 5 (when 316 flowing from Sonet to SDH) 318 - Switching Type: no value change since a single TDM value is 319 defined for both Sonet and SDH switching 321 - Signal Type: no value change since SDH Signal Types values are 322 mapped to their Sonet equivalent 324 - Transparency: in principle no particular rule however, hardware 325 specific implementation may generate some restrictions in 327 Informational Draft � Expires May 2002 6 328 particular when using J0 and MS/Line K1/K2 transparency fields 330 - Contiguous Concatenation: no specific issue to consider since the 331 gateway terminates the overhead providing the needed functions to 332 enable contiguous concatenation interoperability 334 - Virtual Concatenation: FFS 336 5. Security Considerations 338 This draft introduces no new security considerations to [GMPLS- 339 SONET-SDH]. 341 6. References 343 1. [GMPLS-SIG] P.Ashwood-Smith, L.Berger et al, �Generalized MPLS 344 - Signaling Functional Description�, Internet Draft, Work in 345 progress, draft-ietf-mpls-generalized-signaling-06.txt, October 346 2001. 348 2. [GMPLS-LDP] P.Ashwood-Smith, L.Berger et al, �Generalized MPLS 349 Signaling - CR-LDP Extensions�, Internet Draft, Work in progress, 350 draft-ietf-mpls-generalized-cr-ldp-04.txt, July 2001. 352 3. [GMPLS-RSVP] P.Ashwood-Smith, L.Berger et al, �Generalized MPLS 353 Signaling - RSVP-TE Extensions�, Internet Draft, Work in progress, 354 draft-ietf-mpls-generalized-rsvp-te-05.txt, October 2001. 356 4. [GMPLS-SONET-SDH] E. Mannie (Editor) et al, �GMPLS extensions 357 for SONET and SDH control�, Internet Draft, Work in progress, 358 draft-ietf-ccamp-gmpls-sonet-sdh-02.txt, October 2001. 360 5. [GMPLS-SONET-SDH-EXT] E. Mannie (Editor) et al, �GMPLS 361 extensions for SONET and SDH control � Extensions�, Internet 362 Draft, Work in progress, draft-ietf-ccamp-gmpls-sonet-sdh- 363 extensions-00.txt, October 2001. 365 6. [GMPLS-SONET-SDH-CCV] E. Mannie and D. Papadimitriou, �GMPLS 366 Signaling Extension to Control the Conversion between Contiguous 367 and Virtual Concatenation for SONET and SDH�, Internet Draft, Work 368 in progress, draft-ietf-ccamp-gmpls-concatenation-conversion- 369 00.txt, July 2001. 371 7. [GMPLS-SONET-SDH-RTG] E. Mannie et al, �Extensions to OSPF and 372 IS-IS in support of MPLS for SDH/SONET Control�, Internet Draft, 373 Work in progress, draft-mannie-mpls-sdh-ospf-isis-01.txt, July 2001. 375 8. [GMPLS-ARCH] E. Mannie (Editor) et al, �Generalized MPLS 376 Architecture�, Internet Draft, Work in progress, draft-ietf-ccamp- 377 gmpls-architecture-00.txt, June 2001. 379 9. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels," RFC 2119. 382 Informational Draft � Expires May 2002 7 383 7. Authors Addresses 385 Eric Mannie 386 Ebone (GTS) 387 Terhulpsesteenweg 6A 388 1560 Hoeilaart - Belgium 389 Phone: +32 2 658-5652 390 Email: eric.mannie@ebone.com 392 Dimitri Papadimitriou 393 Alcatel 394 Francis Wellesplein 1, 395 B-2018 Antwerpen, Belgium 396 Phone: +32 3 240-8491 397 Email: Dimitri.Papadimitriou@alcatel.be 399 Informational Draft � Expires May 2002 8