idnits 2.17.1 draft-boyle-sts-ip-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 6) being 63 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. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (July 2000) is 8680 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'CRLDP' is mentioned on line 433, but not defined == Unused Reference: 'CR-LDP' is defined on line 472, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-martini-l2circuit-trans-mpls-01 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-trans-mpls (ref. 'Martini') -- No information found for draft-ietf-mpls-lsp-tunnel - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RSVP-TE' == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-04 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jim Boyle 3 Internet Draft Craig White 4 Expiration Date: January 2001 Joe Lawrence 5 Level 3 7 July 2000 9 SONET Synchronous Transport Signal over IP 11 draft-boyle-sts-ip-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 A proposal is made to carry Synchronous Transport Signal 37 (STS-N) services over packetized networks, in particular over IP 38 networks. This has the potential to dramatically lower the price, 39 ease the provisioning and grooming, and improve managability of 40 delivering these types of circuits. Two proposals are put forth for 41 discussion on how STS services could be transported over an IP 42 network. The first proposal, referred to as SPE1/IP, is to break OC-N 43 signals down into their STS-1 blocks, identify the SPE components and 44 packetize these for transmission across a packet network. The second 45 proposal, referred to as STSc/IP breaks down the STS signal into the 46 underlying concatenated services and transports configurable length 47 segments of the signal to the far end of the data network. With 48 either of these approaches, different STS-N services on a given port 49 can be connected to different ports across the network and the 50 network will groom them onto the most optimal path available. 52 Table of Contents 54 1 Specification of Requirements .......................... 3 55 2 Introduction ........................................... 3 56 3 SONET Background ....................................... 4 57 4 Encapsulation Alternatives ............................. 6 58 4.1 SPE-1 transport over IP (SPE1/IP) ...................... 6 59 4.2 STS-Nc transport over IP (STSc/IP) ..................... 8 60 4.3 Comparison of SPE1/IP and STSc/IP ...................... 8 61 5 Issues of Efficiency ................................... 9 62 5.1 Efficiency Losses ...................................... 9 63 5.2 Efficiency Gains ....................................... 9 64 6 Functionality Requirements ............................. 10 65 6.1 Playback buffers on IP/TDM conversion .................. 10 66 6.2 QoS in IP network ...................................... 10 67 6.3 Traffic engineered control plane ....................... 10 68 7 Security Considerations ................................ 11 69 8 Intellectual Property Disclaimer ....................... 11 70 9 Acknowledgements ....................................... 11 71 10 References ............................................. 11 72 11 Author Information ..................................... 11 74 1. Specification of Requirements 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119. 80 2. Introduction 82 Anyone familiar with operating a private line network understands 83 that, even though there maybe additional costs, technologies that 84 ease grooming and provisioning are worth consideration. This is one 85 of the areas where the next generation of transmission equipment is 86 improving by leveraging IP based control protocols and head of 87 service automated provisioning. However, there do exist some issues 88 of multi-vendor compatibility with this approach. This makes an 89 approach where private line services are converted into an open data 90 protocol, such as RTP/IP and/or MPLS attractive. 92 By converting the TDM service to IP, the provider is now also able to 93 use network elements such as ethernet switches which are geared to 94 much wider, mass markets and potentially ride a much more aggressive 95 price/performance curve than standard telecommunication equipment. 97 These benefits were the impetus of the authors investigation into 98 converting high capacity private line services, STS1 and STSNc 99 services in particular, into IP for transport over a data network. 101 Investigation yielded the result that this could likely be done with 102 rather plain technology, as is used in current transmission 103 equipment, and might yield significant network savings due to signal 104 compression potential. 106 This memo is intended as a strawman statement of approach and 107 essential functionality. The description, though written rather 108 close to the physical and network layer, is actually intended to be 109 more in line with a transport protocol, such as RTP. In fact, though 110 this memo is written in the form of a protocol specification, it may 111 well be that this functionality can, and should, be adapted to 112 existing protocols to ease implementation. 114 3. SONET Background 116 SONET, as its name implies, is a hierarchical protocol for 117 synchronously transporting TDM circuits across an optical network. 118 Over the length of a circuit, there is a hierarchical breakdown of 119 functionality which allows for multiplexing, service monitoring and 120 alarming and signal degradation monitoring at high data rates. From 121 end to end, at the highest layer, SONET provides monitoring service 122 via it's Path overhead. This is transported to the customer and 123 allows for continuity verification as well as error calculation over 124 the service payload. The physical optical fiber is often in a 1:1 125 relationship with the section, and often directly corresponds to the 126 line. The difference is that multiple lines usually terminate at a 127 Digital Cross Connect (DACS) or Add Drop Multiplexer (ADM) where 128 synchronization and alignment across lines is required. With the 129 advent of WDM, the section no longer directly corresponds to a fiber, 130 it refers to logically adjacent SONET equipment such as an ADM and a 131 3R. In fact, with some WDM products, it is possible for the WDM 132 equipment to operate in a non section processing, or pass-through, 133 mode in which case the WDM signal has 1:1 parity of Path, Line and 134 Section. Here is a diagram to illustrate SONET's signal hierarchy: 136 |---------------------- Path -----------------------| 137 |--- Line ---|--- Line ---|--- Line ---|--- Line ---| 138 |--- Sect ---| *** See Figure 2 *** |--- Line ---| 139 Router------ADM----------ADM----------ADM------Router 141 Figure 1 - SONET Signal Hierarchy 143 Below is a blowup of one of the ADM-ADM Lines to illustrate how SONET 144 section no longer corresponds directly to a fiber. 146 ADM-----WDM-----ILA-----3R-----ILA-----WDM-----ADM 147 |----------------------Line----------------------| 148 |-----------Sect--------|------------Sect--------| 150 Figure 2 - SONET Line and Section in WDM environment 152 In SONET, the digital signal is referred to as an STS (Synchronous 153 Transport Signal). This signal is broken down into a repetitive 154 series of STS frames, each frame for an STS being generated every 125 155 us (8000 fps). Each frame can be thought of as having 90 columns and 156 9 rows. The first 3 columns contain the section and line overhead. 157 The path overhead is contained within the Synchronous Payload 158 Envelope (SPE). 160 +-----------------------------------------------------+ 161 | | | | ... | 162 | SOH | ... | 163 |_|_|_| ... | 164 | | | | ... PATH OH and Payload | 165 | | | | ... | 166 | LOH | ... | 167 | | | | ... | 168 | | | | ... | 169 | | | | ... | 170 +-----------------------------------------------------+ 172 Figure 3 - STS frame with transport overhead 174 +-----------------------------------------------------+ 175 | | | | | 176 | SOH | | 177 |_|_|_| _____________________________________| 178 | | | |_________| | | 179 | | | | |P| | 180 | LOH | |O| STS-1 SPE | 181 | | | | |H| | 182 | | | | | | | 183 |_|_|_|_ _ _ _ _|N|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| 184 | | | | | | | 185 | SOH | | | | 186 |_|_|_| |_|___________________________________| 187 | | | |_________| | 188 | | | | ... | 189 | LOH | ... | 190 | | | | ... | 191 | | | | ... | 192 | | | | ... | 193 +-----------------------------------------------------+ 195 Figure 4 - STS frame including SPE 197 Notice that the payload floats inside the STS frame. It is 198 referenced in the LOH with a Path Payload Pointer, and can change. 199 This is to allow slight variations in line rates on DACS or ADMs 200 which a path traverses. The LTE can then either byte positive or 201 negative stuff a signal. 203 The basic building block of SONET is the STS-1. This is always 204 carried over a physical facility, in particular a fiber operates at a 205 bit rate which is a specified multiple of STS-1s. The STS-1s are 206 byte multiplexed together as show in Figure 5. 208 STS1-#01 + 209 \ 210 STS1-#02 +-+- #03#02#01 + 211 / \ 212 STS1-#03 + \ 213 \ 214 STS1-#04 + \ 215 \ \ 216 STS1-#05 +-+- #06#05#04 + \ 217 / \___ \ 218 STS1-#06 + \__\ 219 __ + #12#09#06#03#11#08#05#02#10#07#04#01 220 STS1-#07 + ___/ / 221 \ / / 222 STS1-#08 +-+- #09#08#07 + / 223 / / 224 STS1-#09 + / 225 / 226 STS1-#10 + / 227 \ / 228 STS1-#11 +-+- #12#11#10 + 229 / 230 STS1-#12 + 232 Figure 5 - STS-12 multiplexing of underlying STS-1s 234 The byte pattern for the STS-12 presented across an OC-12 236 #12#09#06#03#11#08#05#02#10#07#04#01-> 238 is a byte interleaving of all the STS-1s. In 125 us, a byte from 239 each STS-1 is transmitted over the OC-12 signal. 241 At each SONET switching element, it is customary for the signal to be 242 demultiplexed into the STS-1s into a small buffer and then for the 243 appropriate egress port to pull the signal out of the buffers during 244 its multiplexing. 246 4. Encapsulation Alternatives 248 4.1. SPE-1 transport over IP (SPE1/IP) 250 In this mode, the STS-1s from an STS-N signal are broken down and are 251 written into a buffer. There is no need to forward any LOH or SOH, 252 however it is required to identify and forward the POH so that the 253 customer can monitor continuity and performance. A complete SPE is 254 written out in several SPE segments to a buffer. An SPE segment 255 refers to the portions of an SPE that reside in different STSs. 256 Although the POH for different services within an STS-N structure may 257 be located at different offsets from their respective LOH, the SPE 258 for concatenated STSs must be treated as all at the same offset as 259 the first STS in the concatenated service. The pointer to the start 260 of the SPE is known for all STSs within an existing service, and a 261 complete SPE has been written out to buffer. At this point, the SPE 262 segments are encapsulated and forwarded across the network. The 263 essential information for a header would include: 265 SPE1/IP Header (6 bytes) 266 o Version field (4 bits = 1) 267 o Operation Code, OP, (2 bits) 268 - 00 = standard user data format 269 - 01 = Unused, reserved for extended data format 270 - 10 = OAM 271 - 11 = unused 272 o Parity bit (2 bits) 273 - P0 - bit 1, even parity across header 274 - P1 - bit 2, even parity across entire PDU 275 o STS reference (16 bits) 276 o Sequence number (16 bits) 278 +-------------+-------------+-------------+-------------+ 279 |V |OP|PP | Unused | STS Reference | 280 +-------------+-------------+-------------+-------------+ 281 | Sequence Number | 282 +-------------+-------------+ 284 The sequence number is synchronized across all of the SPE segments of 285 an SPE for a given concatenated service and increases by 1 every 125 286 us. At 8000 fps, it would wrap in just under 8 seconds. If a packet 287 is dropped, then an all 1s segment is inserted in its place for 288 multiplexing into the next line in the service. Bit errors within 289 the frame are noticed by standard SONET monitoring facilities, in 290 this case the B3 byte in the POH will alert the end-user with 291 potentially 1 or 3 BIP-8 violations depending on if the bit error 292 happened in the B3 byte of an SPE or not. For all 1s inserted 293 segments that are multiplexed into an SPE, at least 3 BIP-8 294 violations would occur at the path layer. Bit errors in the 295 encapsulation header are recognized in a non-recoverable fashion by 296 the parity bit P0 which is set or cleared to create even parity 297 across the rest of the header. The packet should be discarded if 298 such a bit error is detected in the encapsulation header. The P1 bit 299 can be used to check parity for bit error across the header and the 300 SPE. This can be done for service management to determine if the 301 data network has an unexpectedly high bit error rate. This is 302 similar to section and line monitoring in a standard SONET network. 303 The STS reference is similar to a UDP port and remains constant for a 304 given STS traversing a node. It is set by the node that converts the 305 STS from the TDM to the IP domain. 307 4.2. STS-Nc transport over IP (STSc/IP) 309 In this mode, the contents of the concatenated SPE are written out to 310 a buffer upon demultiplexing of the TDM line into the TDM/IP 311 conversion platform. The signal is then sampled at a configurable 312 block size, 1000 bytes for example, and this information is 313 encapsulated and sent across the IP network 315 STSc/IP Header (8 bytes) 316 o Version field (4 bits = 1) 317 o Operation Code, OP, (2 bits) 318 - 00 = standard user data format 319 - 01 = Unused, reserved for extended data format 320 - 10 = OAM 321 - 11 = unused 322 o Parity bit (2 bits) 323 o STS reference (16 bits) 324 o Sequence number (32 bits) 326 +-------------+-------------+-------------+-------------+ 327 |V |OP|PP | Unused | STS Reference | 328 +-------------+-------------+-------------+-------------+ 329 | Sequence Number | 330 +-------------+-------------+-------------+-------------+ 332 The number of frames per second are a function of the number of the 333 sample size and the service bit-rate. Sequence number wrap can be 334 derived from that, but with a range of 0 to 2^32-1, a worst case 335 scenario of sampling an OC192 at 100 bytes yields wrap in over 5 336 minutes. Parity bits are as in section 3.2. The POH still must be 337 identified in the transported payload. One approach would be to use 338 integer math on the sequence number and have the concatenated STSc be 339 segmented into chunks which together exactly construct the payload of 340 one frames worth of SPE. Another might be to use an extended data 341 format that points into the payload to identify the start of SPE for 342 each frame. 344 4.3. Comparison of SPE1/IP and STSc/IP 346 SPE1/IP is not very flexible, but in such an approach a certain 347 simplicity is gained. In fact, most TDM gear today is built around 348 breaking down services into STS-1 for switching. STSc/IP is very 349 flexible, but that might add too much complexity to implementation 350 and interoperability. Either approach requires that the service 351 provider be intimate with the channel structure of the OC services 352 they provide, either through static provisioning or through 353 derivation from the LOH. 355 5. Issues of Efficiency 357 5.1. Efficiency Losses 359 As SONET is non-hierarchically built around the STS-1 payload, with 360 direct multiplexing, the overhead remains constant at around 4% (3 361 out of 90 columns, plus POH in first STS-1). It doesn't matter if 362 the services are all STS-1s, or a concatenated service occupying the 363 whole linespeed such as an STS-12c in an OC-12c, there exist LOH and 364 POH for each STS. 366 This creates a bit of an issue when the payload is encapsulated and 367 forwarded out into an IP network. As an example, if one of the core 368 links in a network was a OC-192c, it would not be able to carry 192 369 STS-1s of service, as the IP traffic must itself become SONET payload 370 on this link. In this case, one provisioned service is going to have 371 to take another route, which introduces the need for skew recovery 372 buffers. This could be problematic for networks whose service 373 bandwidth approaches their internal link speeds. Perhaps it is time 374 to try to take use of all those D and E bytes in the SONET header? 375 Even that wouldn't carry the additional 3-5% of overhead incurred by 376 IP encapsulation. One should note that an OC-12 can be routed across 377 a Gigabit Ethernet, and the assumption is that volume and target 378 market of Gigabit Ethernet make it likely cheaper than the 379 corresponding SONET interface. 381 5.2. Efficiency Gains 383 The losses outlined in the previous section appear problematic for 384 this application, however there exists a large potential for reducing 385 the amount of network that has to be built out to support a set of 386 private line services by using technology like this. It may be 387 trivial to remove bandwidth from STS services being used for data 388 transport by compressing predictable frame sequences. Suggested 389 sequences include HDLC idle (0x7Es), STS services that are either in 390 alarm (AIS) or are not in service (unequiped) (all ones), unequiped 391 asynchronous DS3 and idle ATM cells. One approach for compression 392 could be to send a packet that has a the base sequence written just 393 once, and it is to be repeated out to fill out the remainder of the 394 SPE. Another approach, especially for unequiped circuits would be to 395 use signalling to establish state on either end of the circuit 396 reflecting unequiped and transport nothing through the data network. 397 For a carrier who has sold an OC12 structured as 12 STS1, of which 398 only 8 are in service, a significant savings may be realizable. 400 Further efficiency gains can be realized by relaxing the timing 401 precision of the service if the STS payload is HDLC, PPP or FR 402 [Martini]. However, this draft outlines an approach to exactly mimic 403 a TDM based SONET service. 405 6. Functionality Requirements 407 6.1. Playback buffers on IP/TDM conversion 409 The extent of playback buffering required (and user experienced 410 latency) is somewhat traded off with QoS of IP network described in 411 the following section. The playback logic must allow for packets 412 received out of sequence to be ordered correctly and played out in 413 sequence and insertion of all ones payload for packets that didn't 414 arrive in time for enqueue. Also, if the contents of an STS-Nc 415 service take multiple routes through the network, additional skew 416 recovery buffers will be required. 418 6.2. QoS in IP network 420 It is expected that the network is not chronically congested. For a 421 multiservice network, the TDM/IP (and other delay sensitive traffic 422 such as VoIP) can be forwarded without too much delay. However, in 423 conjunction with the previous section, it might not be required that 424 this be strict "next packet served" type queuing. 426 6.3. Traffic engineered control plane 428 There must be a way to keep proper coordination of the traffic 429 assigned to network bandwidth resources. The application requires a 430 way to signal the bandwidth it requires from the network. One 431 potential approach is use of the Resource Reservation Protocol 432 [RSVP]. A more direct approach would be to have the host on which 433 the application runs signal traffic engineered MPLS tunnels [RSVP- 434 TE][CRLDP] between itself and other TDM/IP conversion devices with 435 which it has common services. These tunnels could be sized to 436 accommodate multiple STS services, or sized to carry just one, or a 437 portion of one, STS service. MPLS tunneling would allow the TDP/IP 438 device to find a route for their traffic across the network, 439 potentially find backup routes, and groom their traffic onto new, 440 more optimal paths in the network. The concern would be one of 441 scalability as all TDM/IP devices would have to belong to a common 442 TE-IGP domain. An alternate approach would be for the TDM/IP devices 443 to communicate the bandwidth information of the service via loosely 444 routed TE-LSPs, and to have switches along the way with more complete 445 information insert the route the service should take. 447 7. Security Considerations 449 8. Intellectual Property Disclaimer 451 This document is being submitted for use in IETF standards 452 discussions. Level 3 Communications, Inc. has filed one or more 453 patent applications relating to the technology outlined in this 454 document. 456 9. Acknowledgements 458 This draft has benefited from the discussions and assistance provided 459 by Tom Issenhuth, Jack Waters and Danny McPherson, among others. 461 10. References 463 [Martini] "Transport of Layer 2 Frames Over MPLS", draft-martini- 464 l2circuit-trans-mpls-01.txt (work in progress) 466 [RSVP] "Resource ReSerVation Protocol -- Version 1 Functional 467 Specification", RFC2205 469 [RSVP-TE] "Extensions to RSVP for LSP Tunnels", draft-ietf-mpls-lsp- 470 tunnel-06.txt (work in progress) 472 [CR-LDP] "Constraint-Based LSP Setup Using LDP", draft-ietf-mpls-cr- 473 ldp-04.txt (work in progress) 475 11. Author Information 477 Jim Boyle 478 Level 3 Communications, LLC. 479 1025 Eldorado Blvd. 480 Broomfield, CO 80021 481 e-mail: jboyle@level3.net 482 phone: 720.888.1192 483 Craig White 484 Level 3 Communications, LLC. 485 1025 Eldorado Blvd. 486 Broomfield, CO 80021 487 e-mail: craig.white@level3.com 488 phone: 720.888.2375 490 Joe Lawrence 491 Level 3 Communications, LLC. 492 1025 Eldorado Blvd. 493 Broomfield, CO 80021 494 e-mail: joe.lawrence@level3.com 495 phone: 720.888.1000