idnits 2.17.00 (12 Aug 2021) /tmp/idnits31290/draft-malis-pwe3-sonet-02.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 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 ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 816 has weird spacing: '...vals if neces...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: As discussed in section 5, a CEP de-packetizer MAY or MAY NOT support re-ordering of mis-ordered packets. -- 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 (March 2002) is 7372 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: '481' is mentioned on line 594, but not defined -- Looks like a reference, but probably isn't: '485v2' on line 601 -- Looks like a reference, but probably isn't: 'GR-253' on line 829 == Outdated reference: draft-ietf-pwe3-requirements has been published as RFC 3916 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-requirements (ref. '3') == Outdated reference: A later version (-01) exists of draft-ietf-pwe3-framework-00 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: draft-malis-sonet-ces-mpls has been published as RFC 5143 ** Downref: Normative reference to an Historic draft: draft-malis-sonet-ces-mpls (ref. '7') -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Working Group Andrew G. Malis 3 Internet Draft Ken Hsu 4 Expiration Date: September 2002 Vivace Networks, Inc. 6 Tom Johnson Jeremy Brayley 7 Marlene Drost Steve Vogelsang 8 Ed Hallman John Shirron 9 Litchfield Communications, Inc. Laurel Networks, Inc. 11 Jim Boyle Luca Martini 12 Protocol Driven Networks, Inc. Craig White 13 Level 3 Communications, LLC. 14 Ron Cohen 15 Lycium Networks David Zelig 16 Corrigent Systems, LTD. 17 Prayson Pate 18 Overture Networks, Inc. 20 March 2002 22 SONET/SDH Circuit Emulation over Packet (CEP) 23 draft-malis-pwe3-sonet-02.txt 25 Status of this Memo 27 This document is an Internet-Draft and is in full conformance with 28 all provisions of section 10 of RFC 2026 [1]. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Abstract 48 Generic requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3) have 49 been described in [3]. This draft lists SONET specific requirements 50 and provides encapsulation formats and semantics for connecting SONET 51 edge networks through a core packet network using IP, L2TP or MPLS. 52 This basic application of SONET interworking will allow SONET service 53 providers to take advantage of new technologies in the core in order to 54 provide SONET services. 56 Table of Contents 58 1 Conventions used in this document...........................2 59 2 Introduction................................................2 60 3 Scope.......................................................3 61 4 CEP Encapsulation Format....................................4 62 5 CEP Operation...............................................9 63 6 SONET/SDH Maintenance Signals..............................12 64 7 SONET/SDH Transport Timing.................................16 65 8 SONET/SDH Pointer Management...............................17 66 9 CEP Performance Monitors...................................18 67 10 Open Issues................................................20 68 11 Security Considerations....................................21 69 12 Intellectual Property Disclaimer...........................21 70 13 References.................................................22 71 14 Acknowledgments............................................23 72 15 Author's Addresses.........................................23 74 1 Conventions used in this document 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 [2]. 80 2 Introduction 82 This document describes a protocol that performs SONET Emulation 83 over a variety of Packet-Switched Networks (PSNs) as part of the 84 PWE3 Working Group. The document assumes that the reader is 85 familiar with the PWE3 terminology and concepts described in PWE3 86 requirements and framework documents [3] and [4]. The protocol is 87 titled "Circuit Emulation over Packet" (CEP). 89 The transmission system for circuit-oriented TDM signals is the 90 Synchronous Optical Network (SONET) [5], [9] / Synchronous Digital 91 Hierarchy (SDH) [6]. To support TDM traffic (which includes voice, 92 data, and private leased line services) PSNs must emulate the 93 circuit characteristics of SONET/SDH payloads. A circuit identifer 94 and a CEP header are used to encapsulate the SONET/SDH TDM signals 95 for transmission over an arbitrary PSN. 97 This document also describes an optional extension to CEP called 98 Dynamic Bandwidth Allocation (DBA). This is a method for 99 dynamically reducing the bandwidth utilized by emulated SONET/SDH 100 circuits in the packet network. This bandwidth reduction is 101 accomplished by not sending the SONET/SDH payload through the packet 102 network under certain conditions such as AIS-P or STS SPE 103 Unequipped. 105 This document is based on a previous document describing a method 106 for encapsulating SONET signals for carriage over MPLS networks 107 (CEM) [7]. This document is closely related to [8] which describes 108 a MIB for controlling and observing CEP services. 110 3 Scope 112 This document describes how to provide CEP for the following digital 113 signals: 115 1. SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3 117 2. STS-Nc SPE (N = 3, 12, 48, or 192)/SDH VC-4, VC-4-4c, VC-4-16c, 118 or VC-4-64c 120 For the remainder of this document, these constructs will be 121 referred to as SONET/SDH channels. 123 Although this document currently covers up to OC-192c/VC-4-64c, 124 future revision MAY address higher rates. 126 Other SONET/SDH signals, such as virtual tributary (VT) structured 127 sub-rate mapping, are not explicitly discussed in this document; 128 however, it can be extended in the future to support VT and lower 129 speed non-SONET/SDH services. 131 4 CEP Encapsulation Format 133 In order to transport SONET/SDH SPEs through a packet-oriented 134 network, the SPE is broken into fragments. A Circuit ID Word and 135 CEP Header are pre-pended to each fragment. The basic CEP packet 136 appears in Figure 1. 138 +-----------------------------------+ 139 | Circuit ID Word | 140 +-----------------------------------+ 141 | CEP Header | 142 +-----------------------------------+ 143 | | 144 | | 145 | SONET/SDH SPE Fragment | 146 | | 147 | | 148 +-----------------------------------+ 150 Figure 1. Basic CEP Packet 152 The Circuit ID Word is a 32-bit field that contains an arbitrary 153 value that is used to map CEP packets to specific SONET/SDH 154 channels. The circuit ID word is intentionally designed to match 155 the format of an MPLS shim. 157 0 1 2 3 158 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Circuit ID | Exp |S| TTL | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 2. CEP Circuit ID Word 165 Circuit ID: Matches the Label Position in an MPLS shim. It SHOULD 166 be used to map individual packet streams to SONET channels. 168 Exp: Experimental Use, 3 bits. SHOULD conform to use of Exp bits 169 within an MPLS shim. 171 S: Bottom of Stack, 1 bit. SHOULD be set to 1 to indicate the 172 bottom of an MPLS label stack. 174 TTL: Time to Live, 8 bits. SHOULD be utilized in a manner 175 consistent with the TTL field of an MPLS Shim. 177 The CEP Header supports a basic and extended mode. The Basic CEP 178 Header provides the minimum functionality necessary to accurately 179 emulate a TDM SONET over a PSN. Bit 0 of the first 32-bit CEP 180 header indicates whether or not the extended header is present. 181 When this bit is 0, then no extended header is present. When this 182 bit is 1, then an extended header is present. At this time, the 183 contents of the extended header are for future study. However, it 184 is expected that this field will provide support for payload 185 compression, header protection, enhanced performance monitoring, 186 and/or other extensions to the base protocol. 188 The Basic CEP header has the following format: 190 0 1 2 3 191 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 |0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 3. Basic CEP Header Format 198 The Extended CEP header appears below: 200 0 1 2 3 201 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Reserved | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Figure 4. Extended CEP Header Format 210 The above fields are defined as follows: 212 R bit: CEP-RDI. This bit is set to one to signal to the remote CEP 213 function that a loss of packet synchronization has occurred. See 214 section 5.4 for details. 216 D bit: Signals DBA Mode. MUST be set to zero for Normal Operation. 217 MUST be set to one if CEP is currently in DBA mode. DBA is an 218 optional mode during which trivial SPEs are not transmitted into the 219 packet network. See Table 1 and section 5 for further details. 221 The N and P bits: MAY be used to explicitly relay negative and 222 positive pointer adjustment events across the PSN. They are also 223 used to relay SONET/SDH maintenance signals such as AIS-P. See 224 Table 1 and sections 6 and 8 for more details. 226 +---+---+---+----------------------------------------------+ 227 | D | N | P | Interpretation | 228 +---+---+---+----------------------------------------------+ 229 | 0 | 0 | 0 | Normal Mode - No Ptr Adjustment | 230 | 0 | 0 | 1 | Normal Mode - Positive Ptr Adjustment | 231 | 0 | 1 | 0 | Normal Mode - Negative Ptr Adjustment | 232 | 0 | 1 | 1 | Normal Mode - AIS-P | 233 | | | | | 234 | 1 | 0 | 0 | DBA Mode - STS SPE Unequipped | 235 | 1 | 0 | 1 | DBA Mode - STS SPE Unequipped Pos Ptr Adj | 236 | 1 | 1 | 0 | DBA Mode - STS SPE Unequipped Neg Ptr Adj | 237 | 1 | 1 | 1 | DBA Mode - AIS-P | 238 +---+---+---+----------------------------------------------+ 240 Table 1. Interpretation of D, N, and P bits 242 Sequence Number[0:13]: This is a packet sequence number, which MUST 243 continuously cycle from 0 to 0x3FFF. It SHOULD begin at zero when a 244 CEP channel is created. 246 Structure Pointer[0:12]: The Structure Pointer MUST contain the 247 offset of the J1 byte within the CEP SPE Fragment. The value is 248 from 0 to 0x1FFE, where 0 means the first byte after the CEP header. 249 The Structure Pointer MUST be set to 0x1FFF if a packet does not 250 carry the J1 byte. See [5], [6] and [9] for more information on the 251 J1 byte and the SONET/SDH payload pointer. Implementations MUST 252 support SPE Fragments of 783 bytes and MAY support SPE fragments of 253 from 8 to 8191 bytes. 255 Note 1: Implementations that choose to support programmable payload 256 lengths SHOULD support payloads that are an integer multiple of 8 257 bytes. 259 Note 2: CEP packets are fixed in length for all of the packets of a 260 particular emulated TDM stream. This length is statically 261 provisioned for each TDM stream. Therefore, the length of each CEP 262 packet does not need to be carried in the CEP header. 264 4.1 PSN Encapsulation 266 In principle, CEP packets can be carried over any packet-oriented 267 network. The following sections describe specifically how CEP 268 packets MUST be encapsulated for carriage over MPLS or IP networks. 270 4.1.1 MPLS Encapsulation 272 To transport a CEP packet over an MPLS network, an MPLS label-stack 273 MUST be pushed on top of the CEP packet. 275 +-----------------------------------+ 276 | MPLS Label Stack | 277 +-----------------------------------+ 278 | Circuit ID Word | 279 +-----------------------------------+ 280 | CEP Header | 281 +-----------------------------------+ 282 | | 283 | | 284 | SONET/SDH SPE Fragment | 285 | | 286 | | 287 +-----------------------------------+ 289 Figure 5. Typical MPLS Transport Encapsulation 291 4.1.2 IP Encapsulation 293 It is highly desirable to define a single encapsulation format that 294 will work for both IP and MPLS. Furthermore, it is desirable that 295 the encapsulation mechanism be as efficient as possible. 297 One way to achieve these goals is to map CEP directly onto IP. 298 Because the Circuit ID Word is essentially an MPLS Shim, the CEP 299 packet may be treated as an MPLS packet. A mechanism for carrying 300 MPLS over IP is described in [10]. 302 Using this encapsulation scheme would result in the packet format 303 illustrated in figure 6. 305 +-----------------------------------+ 306 | | 307 | IPv6/v4 Header [10] | 308 | | 309 +-----------------------------------+ 310 | Circuit ID Word | 311 +-----------------------------------+ 312 | CEP Header | 313 +-----------------------------------+ 314 | | 315 | | 316 | SONET/SDH SPE Fragment | 317 | | 318 | | 319 +-----------------------------------+ 321 Figure 6. MPLS Transport Encapsulation 323 4.1.3 L2TP Encapsulation 325 Encapsulation for L2TP PSNs is for future study. 327 5 CEP Operation 329 The following sections describe CEP operation. 331 5.1 Introduction and Terminology 333 CEP MUST support a normal mode of operation and MAY support an 334 optional extension called Dynamic Bandwidth Allocation (DBA). 335 During normal operation, SONET/SDH payloads are fragmented, pre- 336 pended with the CEP Header, the Circuit ID Word, and the PSN header, 337 and then transmitted into the packet network. During DBA mode, only 338 the CEP header, the Circuit ID Word, and PSN header are transmitted. 339 This is done to conserve bandwidth when meaningful user data is not 340 present in the SPE, such as during AIS-P or STS SPE Unequipped. 342 5.1.1 CEP Packetizer and De-Packetizer 344 As with all adaptation functions, CEP has two distinct components: 345 adapting TDM SONET/SDH into a CEP packet stream, and converting the 346 CEP packet stream back into a TDM SONET/SDH. The first function 347 will be referred to as CEP Packetizer and the second as CEP De- 348 Packetizer. This terminology is illustrated in figure 7. 350 +------------+ +---------------+ 351 | | | | 352 SONET --> | CEP | --> PSN --> | CEP | --> SONET 353 SDH | Packetizer | | De-Packetizer | SDH 354 | | | | 355 +------------+ +---------------+ 357 Figure 7. CEP Terminology 359 Note: the CEP de-packetizer requires a buffering mechanism to 360 account for delay variation in the CEP packet stream. This 361 buffering mechanism will be generically referred to as the CEP 362 jitter buffer. 364 5.1.2 CEP DBA 366 DBA is an optional mode of operation that only transmits the CEP 367 Header, the Circuit ID Word, and PSN Header into the packet network 368 under certain circumstances such as AIS-P or STS Unequipped. 370 If DBA is supported by a CEP implementation, the user SHOULD be able 371 to configure if DBA will be triggered by AIS-P, STS Unequipped, 372 both, or neither on a per channel basis. 374 If DBA is supported, the determination of AIS-P and STS Unequipped 375 MUST be based on the state of SONET/SDH Section, Line, and Path 376 Overhead bytes. 378 During AIS-P, there is no valid payload pointer, so pointer 379 adjustments cannot occur. During STS Unequipped, the SONET/SDH 380 payload pointer is valid, and therefore pointer adjustments MUST be 381 supported even during DBA. See Table 1 for details. 383 5.2 Description of Normal CEP Operation 385 During normal operation, the CEP packetizer will receive a fixed 386 rate byte stream from a SONET/SDH interface. When a packets worth 387 of data has been received from a SONET/SDH channel, the CEP Header, 388 the Circuit ID Word, and PSN Header are pre-pended to the SPE 389 fragment and the resulting CEP packet is transmitted into the packet 390 network. Because all CEP packets associated with a specific 391 SONET/SDH channel will have the same length, the transmission of CEP 392 packets for that channel SHOULD occur at regular intervals. 394 At the far end of the packet network, the CEP de-packetizer will 395 receive packets into a jitter buffer and then play out the received 396 byte stream at a fixed rate onto the corresponding SONET/SDH 397 channel. The jitter buffer SHOULD be adjustable in length to 398 account for varying network delay behavior. The receive packet rate 399 from the packet network should be exactly balanced by the 400 transmission rate onto the SONET/SDH channel, on average. The time 401 over which this average is taken corresponds to the depth of the 402 jitter buffer for a specific CEP channel. 404 The CEP sequence numbers provide a mechanism to detect lost and/or 405 mis-ordered packets. The CEP de-packetizer MUST detect lost or mis- 406 ordered packets. The CEP de-packetizer SHOULD play out an all ones 407 pattern (AIS) in place of any dropped packets. The CEP de- 408 packetizer MAY re-order packets received out of order. If the CEP 409 de-packetizer does not support re-ordering, it must drop mis-ordered 410 packets. 412 5.3 Description of CEP Operation during DBA 414 There are several issues that should be addressed by a workable CEP 415 DBA mechanism. First, when DBA is invoked, there should be a 416 substantial savings in bandwidth utilization in the packet network. 417 The second issue is that the transition in and out of DBA should be 418 tightly coordinated between the local CEP packetizer and CEP de- 419 packetizer at the far side of the packet network. A third is that 420 the transition in and out of DBA should be accomplished with minimal 421 disruption to the adapted data stream. 423 Another goal is that the reduction of CEP traffic due to DBA should 424 not be mistaken for a fault in the packet network or vice-versa. 425 Finally, the implementation of DBA should require minimal 426 modifications beyond what is necessary for the nominal CEP case. 427 The mechanism described below is a reasonable balance of these 428 goals. 430 During DBA, packets MUST be emitted at exactly the same rate as they 431 would be during normal operation. This SHOULD be accomplished by 432 transmitting each DBA packet after a complete packet of data has 433 been received from the SONET/SDH channel. The only change from 434 normal operation is that the CEP packets during DBA MUST only carry 435 the CEP header, the Circuit ID Word, and the PSN Header. Because 436 some links have a minimum supported packet size, the CEP packetizer 437 MAY append a configurable number of bytes immediately after the CEP 438 header to pad out the CEP packet to reach the mimumum supported 439 packet size. The D-bit MUST be set to one, to indicate that DBA is 440 active. 442 The CEP de-packetizer MUST assume that each packet received with the 443 D-bit set represents a normal-sized packet containing an AIS-P or 444 SPE Unequipped payload as noted by N and P. See Table 1. The CEP 445 de-packetizer MUST accept DBA packets with or without padding. 447 This allows the CEP packetization and de-packetization logic during 448 DBA to be similar to the nominal case. It ensures that the correct 449 SONET/SDH indication is reliably transmitted between CEP adaptation 450 points. It minimizes the risk of under or over running the jitter 451 buffer during the transition in and out of DBA, since packets are 452 continuously transmitted during DBA. And, it guarantees that faults 453 in the packet network are recognized as distinctly different from 454 line conditioning on the SONET/SDH interfaces. 456 5.4 Packet Synchronization 458 A key component in declaring the state of a CEP service is whether 459 or not the CEP de-packetizer is in or out of packet synchronization. 460 The following paragraphs describe how that determination is made. 462 As discussed in section 5, a CEP de-packetizer MAY or MAY NOT 463 support re-ordering of mis-ordered packets. 465 As packets are received from the PSN, they are placed into a jitter 466 buffer prior to play out on the SONET interface. If a CEP de- 467 packetizer supports re-ordering, any packet received before it's 468 play out time will still be considered valid. 470 If a CEP de-packetizer does not support re-ordering, a number of 471 approaches may be used to minimize the impact of mis-ordered or lost 472 packets on the final re-assembled SONET stream. For example, AAL1 473 [11] uses a simple state-machine to re-order packets in a sub-set of 474 possible cases. The algorithm for these state-machines is outside 475 of the scope of CEP. 477 However, the final determination as to whether or not to declare 478 acquisition or loss of packet synchronization MUST be based on the 479 same criteria regardless of whether an implementation supports or 480 does not support re-ordering. 482 Therefore, the determination of acquisition or loss of packet 483 synchronization is always made at SONET play-out time. During SONET 484 play-out, the CEP de-packetizer will play received CEP packets onto 485 the SONET interface. However, if the jitter buffer is empty or the 486 packet to be played out has not been received, the CEP de-packetizer 487 will have to play out an empty packet onto the SONET interface in 488 place of the unavailable packet. 490 The acquisition of packet synch is based on the number of sequential 491 CEP packets that are played onto the SONET interface. While, loss 492 of packet synch is based on the number of sequential 'empty' packets 493 that are played onto the SONET interface. Specific details of these 494 two cases is described below. 496 5.4.1 Acquisition of Packet Synchronization 498 At startup, a CEP de-packetizer will be out of packet 499 synchronization by default. To declare packet synchronization at 500 startup or after a loss of packet synchronization, the CEP de- 501 packetizer must play-out a configurable number of CEP packets with 502 sequential sequence numbers towards the SONET interface. 504 5.4.2 Loss of Packet Synchronization 506 Once a CEP de-packetizer is in packet sync, it may encounter a set 507 of events that will cause it to lose packet synchronization. 509 If the CEP de-packetizer encounters more than a configurable number 510 of sequentialempty packets, the CEP de-packetizer MUST declare loss 511 of packet synchronization defect . 513 LOPS failure is declared after 2.5 +/- 0.5 seconds of LOPS defect, 514 and cleared after 10 seconds free of LOPS defect state. The VC is 515 considered down as long as LOPS failure is declared. 517 6 SONET/SDH Maintenance Signals 519 There are several issues that must be considered in the mapping of 520 maintenance signals between SONET/SDH and a PSN. A description of 521 how these signals and conditions are mapped between the two domains 522 is described below. 524 For clarity, the mappings are split into two groups: SONET/SDH to 525 PSN, and PSN to SONET/SDH. 527 6.1 SONET/SDH to PSN 528 The following sections describe how SONET/SDH Maintenance Signals 529 and Alarm conditions are mapped into a Packet Switched Network. 531 6.1.1 AIS-P Indication 533 In a SONET/SDH network, SONET Path outages are signaled using 534 maintenance alarms such as Path AIS (AIS-P). In particular, AIS-P 535 indicates that the SONET/SDH Path is not currently transmitting 536 valid end-user data, and the SPE contains all ones. 538 It should be noted that nearly every type of service-effecting 539 section or line defect will result in an AIS-P condition. 541 The SONET/SDH hierarchy is illustrated below. 543 +----------+ 544 | PATH | 545 +----------+ 546 ^ 547 | 548 AIS-P 549 | 550 | 551 +----------+ 552 | LINE | 553 + ---------+ 554 ^ ^ 555 | | 556 AIS-L +------ LOP 557 | 558 | 559 +----------+ 560 | SECTION | 561 +----------+ 562 ^ ^ 563 | | 564 | | 565 LOS LOF 567 Figure 8. SONET/SDH Fault Hierarchy. 569 Should the Section Layer detect a Loss of Signal (LOS) or Loss of 570 Frame (LOF) condition, it sends AIS-L up to the Line Layer. If the 571 Line Layer detects AIS-L or Loss of Path (LOP), it sends AIS-P to 572 the Path Layer. 574 In normal mode during AIS-P, CEP packets are generated as usual. 575 The N and P bits MUST be set to 11 binary to signal AIS-P explicitly 576 through the packet network. The D-bit MUST be set to zero to 577 indicate that the SPE is being carried through the packet network. 578 Normal CEP packets with the SPE fragment, CEP Header, the Circuit ID 579 Word, and PSN Header MUST be transmitted into the packet network. 581 However, to conserve network bandwidth during AIS-P, DBA MAY be 582 employed. If DBA has been enabled for AIS-P and AIS-P is currently 583 occurring, the N and P bits MUST be set to 11 binary to signal AIS, 584 and the D-bit MUST be set to one to indicate that the SPE is not 585 being carried through the packet network. Only the CEP header, the 586 Circuit ID Word, and the PSN Header MUST be transmitted into the 587 packet network. 589 6.1.2 STS SPE Unequipped Indication 591 The declaration of STS SPE unequipped MUST conform to [9]. Quoted 592 below: 594 "R6-135 [481] STS PTE shall detect an STS Path Unequipped (UNEQ-P) 595 defect within 10 ms of the onset of at least five consecutive 596 samples (which may or may not be consecutive frames) of unequipped 597 STS Signal Labels (C2 byte), as specified in Table 6-2" 599 The termination of STS SPE unequipped MUST also conform to [9]. 601 "R6-137 [485v2] STS PTE shall terminate an UNEQ-P defect within 10 602 ms of the onset of at least five consecutive samples (which may or 603 may not be consecutive frames) of STS Signal Labels that are not 604 unequipped or all-ons, as specified in Table 6-2" 606 For normal operation during SPE Unequipped, the N and P bits MUST be 607 interpreted as usual. The SPE MUST be transmitted into the packet 608 network along with the CEP Header, the Circuit ID Word, and PSN 609 Header, and the D-Bit MUST be set to zero. 611 If DBA has been enabled for STS SPE Unequipped and the Unequipped is 612 occurring on the SONET/SDH channel, the D-bit MUST be set to one to 613 indicate DBA is active. Only the CEP Header, the Circuit ID Word, 614 and PSN Header MUST be transmitted into the packet network. The N 615 and P bits MAY be used to signal pointer adjustments as normal. See 616 Table 1 and section 5 for details. 618 6.1.3 CEP-RDI 620 The CEP function MUST send CEP-RDI towards the packet network during 621 loss of packet synchronization. This MUST be accomplished by 622 setting the R bit to one in the CEP header. 624 6.2 PSN to SONET/SDH 626 The following sections discuss how the various conditions on the 627 packet network are converted into SONET/SDH indications. 629 6.2.1 AIS-P Indication 630 There are several conditions in the packet network that will cause 631 the CEP de-packetization function to play out an AIS-P indication 632 towards a SONET/SDH channel. 634 The first of these is the receipt of CEP packets with the N and P 635 bits set to one, and the D-bit set to zero. This is an explicit 636 indication of AIS-P being received at the far-end of the packet 637 network, with DBA disabled for AIS-P. The CEP de-packetizer MUST 638 play out the received SPE fragment (which will incidentally be 639 carrying all ones), and MUST configure the SONET/SDH Overhead to 640 signal AIS-P as defined in [5], [6], and [9]. 642 The second case is the receipt of CEP packets with the N and P bits 643 set to one, and the D-bit set to one. This indicates that AIS-P is 644 being received at the far-end of the packet network, with DBA 645 enabled for AIS-P. The CEP de-packetizer MUST play out one packet's 646 worth of all ones for each packet received, and MUST configure the 647 SONET/SDH Overhead to signal AIS-P as defined in [5], [6], and [9]. 649 A third case that will cause a CEP de-packetization function to play 650 out an AIS-P indication onto a SONET/SDH channel is during loss of 651 packet synchronization. The CEP de-packetizer MUST configure the 652 SONET/SDH Overhead to signal AIS-P as defined in [5], [6], and [9]. 654 6.2.2 STS SPE Unequipped Indication 656 There are three conditions in the packet network that will cause the 657 CEP function to transmit STS SPE Unequipped indications onto the 658 SONET/SDH channel. 660 The first, which is transparent to CEP, is the receipt of regular 661 CEP packets that happen to be carrying an SPE that contains the 662 appropriate Path overhead to signal STS SPE unequipped. This case 663 does not require any special processing on the part of the CEP de- 664 packetizer. 666 The second case is the receipt of CEP packets that have the D-bit 667 set to one to indicate DBA active and the N and P bits set to 00 668 binary, 01 binary, or 10 binary to indicate SPE Unequipped with or 669 without pointer adjustments. The CEP de-packetizer MUST use this 670 information to transmit a packet of all zeros onto the SONET/SDH 671 interface, and adjust the payload pointer as necessary. 673 The third case when a CEP de-packetizer MUST play out an STS SPE 674 Unequipped Indication towards the SONET interface is when the VC- 675 label has been withdrawn due to de-provisioning of the circuit. 677 7 SONET/SDH Transport Timing 679 It is assumed that the distribution of SONET/SDH Transport timing 680 information is addressed through external mechanisms such as 681 Building Integrated Timing System (BITS), Global Positioning System 682 (GPS) or other such methods and is therefore outside of the scope of 683 this specification. 685 8 SONET/SDH Pointer Management 687 A pointer management system is defined as part of the definition of 688 SONET/SDH. Details on SONET/SDH pointer management can be found in 689 [5], [6], and [9]. If there is a frequency offset between the frame 690 rate of the transport overhead and that of the SONET/SDH SPE, then 691 the alignment of the SPE shall periodically slip back or advance in 692 time through positive or negative stuffing. 694 The emulation of this aspect of SONET networks may be accomplished 695 using a variety of techniques including (but not limited to) 696 explicit pointer adjustment relay (EPAR) and adaptive pointer 697 management (APM). 699 In any case, the handling of the SPE data by the CEP packetizer is 700 the same. 702 During a negative pointer adjustment event, the CEP packetizer MUST 703 incorporate the H3 byte from the SONET/SDH stream into the CEP 704 packet payload in order with the rest of the SPE. During a positive 705 pointer adjustment event, the CEP de-packetizer MUST strip the stuff 706 byte from the CEP packet payload. 708 When playing out a negative pointer adjustment event, the 709 appropriate byte of the CEP payload MUST be placed into the H3 byte 710 of the SONET/SDH stream. When playing out a positive pointer 711 adjustment, the CEP de-packetizer MUST insert a stuff-byte into the 712 appropriate position within the SONET/SDH stream. 714 The details regarding the use of the H3 byte and stuff byte during 715 positive and negative pointer adjustments can be found in [5], [6], 716 and [9]. 718 8.1 Explicit Pointer Adjustment Relay (EPAR) 720 CEP provides an OPTIONAL mechanism to explicitly relay pointer 721 adjustment events from one side of the PSN to the other. This 722 technique will be referred to as Explicit Pointer Adjustment Relay 723 (EPAR). The mechanics of EPAR are described below. 725 The following text only applies to implementations that choose to 726 implement EPAR. Any CEP implementation that does not support EPAR 727 MUST either set the N and P bits to zero or utilize them to relay 728 AIS-P and STS Unequipped as shown in table 1. 730 If EPAR is being used, the pointer adjustment event MUST be 731 transmitted in three consecutive packets by the packetizer. The de- 732 packetizer MUST play out the pointer adjustment event when any one 733 packet with N/P bit set is received. 735 References [5],[6],and [9] specify that pointer adjustment events 736 MUST be separated by three SONET/SDH frames without a pointer 737 adjustment event. In order to explicitly relay all legal pointer 738 adjustment events, the packet size for a specific circuit SHOULD be 739 no larger than (783 * 4 * N)/3, where N is the STS-Nc multiplier. 741 However, there are SONET implementations that allow pointer 742 adjustments to occur in back to back SONET/SDH frames. In order to 743 support this possibility, EPAR implementations SHOULD set the packet 744 size for a particular circuit to be no larger than (783*N)/3. Where 745 N is the STS-Nc multiplier. 747 Since the minimum value of N is one, EPAR implementations SHOULD 748 support a minimum payload length of 783/3 or 261 bytes. 750 For EPAR implementations, the CEP de-packetizer MUST utilize the CEP 751 sequence numbers to insure that SONET/SDH pointer adjustment events 752 are not played any more frequently than once per every three CEP 753 packets transmitted by the remote CEP packetizer. 755 If both bits are set, then an AIS-P event has occurred (this is 756 further discussed in section 6). 758 When DBA is invoked (i.e. the D-bit = 1), N and P have additional 759 meanings. See Table 1 and section 5. 761 8.2 Adaptive Pointer Management (APM) 763 Another OPTIONAL method that may be used to emulate SONET pointer 764 management is Adaptive Pointer Management (APM). In basic terms, 765 APM uses information about the depth of the CEP jitter buffers to 766 introduce pointer adjustments in the reassembled SONET SPE. 768 Details about specific APM algorithms is for future study. 770 9 CEP Performance Monitors 772 SONET/SDH as defined in [5], [6], and [9], includes the definition 773 of several counters that may be used to monitor the performance of 774 SONET/SDH services. These counters are referred to as Performance 775 Monitors. 777 In order for CEP to be utilized by traditional SONET/SDH network 778 operators, CEP SHOULD provide similar functionality. To this end, 779 the following sections describe a number of counters that will 780 collectively be referred to as CEP Performance Monitors. 782 9.1 Near-End Performance Monitors 784 These performance monitors are maintained by the CEP De-Packetizer 785 during reassembly of the SONET stream. 787 The performance monitors are based on two types of defects. 789 Type 1 defect is defined as: missing or dropped packet. 790 Type 2 defect is defined as: buffer under run, buffer over-run, 791 LOPS. 793 The specific performance monitors that are defined for CEP are as 794 follows: 796 ES-CEP - CEP Errored Seconds 797 SES-CEP - CEP Severely Errored Seconds 798 UAS-CEP - CEP Unavailable Seconds 800 Each second that contain at least one type 1 defect SHALL be 801 declared as ES-CEP. 803 Each second that contain type 2 defect, or missing packets above 804 pre-defined, configurable threshold of missing/dropped packets SHALL 805 be declared both SES-CEP and ES-CEP. Default value for missing 806 packet to SES is 3. 808 UAS-CEP SHALL be declared after X consecutives SES-CEP, cleared 809 after X consecutive seconds without SES-CEP. Default value of X is 810 10 seconds. 812 Once unavailability is declared, ES and SES counts SHALL be 813 inhibited up to the point where the unavailability was started. Once 814 unavailability is removed, ES that occurred along the X seconds 815 clearing period SHALL be added to the ES counts. An update is 816 required even for closed intervals if necessary. 818 FC-CEP is the number of time type 1 or type 2 defect states were 819 declared. The NE SHALL have thresholding on ES-CEP, SES-CEP and 820 UAS-CEP (thresholding mean activate a notification if more than pre- 821 defined # of seconds are declared as ES, etc. in 15 minutes 822 interval). 823 9.2 Far-End Performance Monitors 825 These performance monitors provide insight into the CEM De- 826 packetizer at the far-end of the PSN. 828 Far end statistics are based on the RDI-CEP bit. Limited 829 functionality is supported compared to [GR-253] for simplicity and 830 because it is assumed that all relevant statistics are available 831 from the end point of the PW. CEP-FE defect is declared when CEP-RDI 832 is set in the incoming CEP packets. 834 CEP-FE failure declared after 2.5 +/- 0.5 seconds of CEP-FE defect, 835 and cleared after 10 seconds free of CES-FE defect state. Sending 836 notification to the OS for CEP-FE failure is local policy. 838 This draft does not attempt to define SES-CEPFE, UAS-CEPFE and FC- 839 CEPFE, but they can be added if to fully emulate GR-253 far end PM 840 (thresholding is required too here except for FC-CEPFE). (Note that 841 ES-CEPFE is not relevant since CEP does not report back missing 842 packets - only LOPS which is SES). 844 The definition of additional performance monitors is for future 845 study. 847 10 Open Issues 849 This version of the draft does not address payload compression 850 within the emulated SONET. Payload compression is expected to be 851 supported by future versions of this draft by utilizing the extended 852 CEP header. 854 This version of the draft does not tie into PWE3 maintenance 855 mechanisms for the setup and tear down of services. That short- 856 coming will be addressed in future revisions of this document. 858 Underlying MPLS QoS requirements are not covered by this revision of 859 the draft. Future revisions may discuss underlying QoS 860 requirements. 862 Support for VT and lower speed non-SONET/SDH services are not 863 covered in this revision of the draft. Future revisions may address 864 VT and non-SONET/SDH TDM services. 866 An alternate version of DBA has been suggested that would suppress 867 transmission of the entire CEP packet stream under certain 868 circumstances. Future versions of this draft may define such a 869 mechanism. 871 11 Security Considerations 873 This document does not address or modify security issues within the 874 relevant PSNs. 876 12 Intellectual Property Disclaimer 878 This document is being submitted for use in IETF standards 879 discussions. Vivace Networks, Inc. has filed one or more patent 880 applications relating to the CEP technology outlined in this 881 document. Vivace Networks, Inc. will grant free unlimited licenses 882 for use of this technology. 884 13 References 886 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 887 BCP 9, RFC 2026, October 1996. 889 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 890 Levels", BCP 14, RFC 2119, March 1997 892 [3] Xiao et al, " Requirements for Pseudo-Wire Emulation Edge-to- 893 Edge (PWE3)", draft-ietf-pwe3-requirements-02.txt, work in 894 progress, Nov 2001 896 [4] Pate et al, "Framework for Pseudo Wire Emulation Edge-to-Edge 897 (PWE3)", draft-ietf-pwe3-framework-00.txt, work in progress, 898 Feb, 2002 900 [5] American National Standards Institute, "Synchronous Optical 901 Network (SONET) - Basic Description including Multiplex 902 Structure, Rates and Formats," ANSI T1.105-1995. 904 [6] ITU Recommendation G.707, "Network Node Interface For The 905 Synchronous Digital Hierarchy", 1996. 907 [7] Malis et al, "SONET/SDH Circuit Emulation Service Over MPLS 908 (CEM) Encapsulation", draft-malis-sonet-ces-mpls-05.txt, work 909 in progress, July 2001. 911 [8] Danenberg et al, "SONET/SDH Circuit Emulation Service Over PSN 912 (CEP) Management Information Base Using SMIv2", draft- 913 danenberg-pw-cem-mib-02.txt, work in progress, Feb 2002. 915 [9] Telcordia Technologies, "Synchronous Optical Network (SONET) 916 Transport Systems: Common Generic Criteria", GR-253-CORE, Issue 917 3, September 2000. 919 [10] Worster, "MPLS Label Stack Encapsulation in IP", draft- 920 worster-mpls-in-ip-05, work in progress, July 2001. 922 [11] ITU-T, "Recommendation I.363.1, B-ISDN Adaptation Layer 923 Specification: Type AAL1", Appendix III, August 1996. 925 14 Acknowledgments 927 The authors would like to thank all the members of the PWE3 WG who 928 have contributed to this effort. 930 15 Author's Addresses 932 Andrew G. Malis 933 Vivace Networks, Inc. 934 2730 Orchard Parkway 935 San Jose, CA 95134 936 Email: Andy.Malis@vivacenetworks.com 938 Ken Hsu 939 Vivace Networks, Inc. 940 2730 Orchard Parkway 941 San Jose, CA 95134 942 Email: Ken.Hsu@vivacenetworks.com 944 Jeremy Brayley 945 Laurel Networks, Inc. 946 2706 Nicholson Rd. 947 Sewickley, PA 15143 948 Email: jbrayley@laurelnetworks.com 950 Steve Vogelsang 951 Laurel Networks, Inc. 952 2706 Nicholson Rd. 953 Sewickley, PA 15143 954 Email: sjv@laurelnetworks.com 956 John Shirron 957 Laurel Networks, Inc. 958 2607 Nicholson Rd. 959 Sewickley, PA 15143 960 Email: jshirron@laurelnetworks.com 962 Luca Martini 963 Level 3 Communications, LLC. 964 1025 Eldorado Blvd. 965 Broomfield, CO 80021 966 Email: luca@level3.net 968 Tom Johnson 969 Litchfield Communications, Inc. 970 76 Westbury Park Rd. 971 Watertown, CT 06795 972 Email: tom_johnson@litchfieldcomm.com 973 Ed Hallman 974 Litchfield Communications, Inc. 975 76 Westbury Park Rd. 976 Watertown, CT 06795 977 Email: ed_hallman@litchfieldcomm.com 979 Marlene Drost 980 Litchfield Communications, Inc. 981 76 Westbury Park Rd. 982 Watertown, CT 06795 983 Email: marlene_drost@litchfieldcomm.com 985 Jim Boyle 986 Protocol Driven Networks, Inc. 987 1381 Kildaire Farm #288 988 Cary, NC 27511 989 Email: jboyle@pdnets.com 991 David Zelig 992 Corrigent Systems LTD. 993 126, Yigal Alon st. 994 Tel Aviv, ISRAEL 995 Email: davidz@corrigent.com 997 Ron Cohen 998 Lycium Networks 999 Hamanofim 9, POB 12256 1000 Herzeliya, Israel 46733 1001 Email: ronc@lyciumnetworks.com 1003 Prayson Pate 1004 Overture Networks 1005 P. O. Box 14864 1006 RTP, NC, USA 27709 1007 Email: prayson.pate@overturenetworks.com 1009 Craig White 1010 Level3 Communications, LLC. 1011 1025 Eldorado Blvd, 1012 Broomfield CO 80021 1013 Email: Craig.White@Level3.com 1014 Appendix A. SONET/SDH Rates and Formats 1016 For simplicity, the discussion in this section uses SONET 1017 terminology, but it applies equally to SDH as well. SDH-equivalent 1018 terminology is shown in the tables. 1020 The basic SONET modular signal is the synchronous transport signal- 1021 level 1 (STS-1). A number of STS-1s may be multiplexed into higher- 1022 level signals denoted as STS-N, with N synchronous payload envelopes 1023 (SPEs). The optical counterpart of the STS-N is the Optical Carrier- 1024 level N, or OC-N. Table 2 lists standard SONET line rates discussed 1025 in this document. 1027 OC Level OC-1 OC-3 OC-12 OC-48 OC-192 1028 SDH Term - STM-1 STM-4 STM-16 STM-64 1029 Line Rate(Mb/s) 51.840 155.520 622.080 2,488.320 9,953.280 1031 Table 2. Standard SONET Line Rates 1033 Each SONET frame is 125 us and consists of nine rows. An STS-N frame 1034 has nine rows and N*90 columns. Of the N*90 columns, the first N*3 1035 columns are transport overhead and the other N*87 columns are SPEs. 1036 A number of STS-1s may also be linked together to form a super-rate 1037 signal with only one SPE. The optical super-rate signal is denoted 1038 as OC-Nc, which has a higher payload capacity than OC-N. 1040 The first 9-byte column of each SPE is the path overhead (POH) and 1041 the remaining columns form the payload capacity with fixed stuff 1042 (STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1 1043 columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed 1044 stuff, STS-12c has three columns of fixed stuff, and so on. 1046 The POH of an STS-1 or STS-Nc is always nine bytes in nine rows. The 1047 payload capacity of an STS-1 is 86 columns (774 bytes) per frame. 1048 The payload capacity of an STS-Nc is (N*87)-(N/3) columns per frame. 1049 Thus, the payload capacity of an STS-3c is (3*87 - 1)*9 = 2,340 1050 bytes per frame. As another example, the payload capacity of an STS- 1051 192c is 149,760 bytes, which is 64 times the capacity of an STS-3c. 1053 There are 8,000 SONET frames per second. Therefore, the SPE size, 1054 (POH plus payload capacity) of an STS-1 is 783*8*8,000 = 50.112 1055 Mb/s. The SPE size of a concatenated STS-3c is 2,349 bytes per frame 1056 or 150.336 Mb/s. The payload capacity of an STS-192c is 149,760 1057 bytes per frame, which is equivalent to 9,584.640 Mb/s. Table 2 1058 lists the SPE and payload rates supported. 1060 SONET STS Level STS-1 STS-3c STS-12c STS-48c STS-192c 1061 SDH VC Level - VC-4 VC-4-4c VC-4-16c VC-4-64c 1062 Payload Size(Bytes) 774 2,340 9,360 37,440 149,760 1063 Payload Rate(Mb/s) 49.536 149.760 599.040 2,396.160 9,584.640 1064 SPE Size(Bytes) 783 2,349 9,396 37,584 150,336 1065 SPE Rate(Mb/s) 50.112 150.336 601.344 2,405.376 9,621.504 1067 Table 2. Payload Size and Rate 1069 To support circuit emulation, the entire SPE of a SONET STS or SDH 1070 VC level is encapsulated into packets, using the encapsulation 1071 defined in section 4, for carriage across packet-switched networks. 1073 Full Copyright Statement 1075 Copyright (C) The Internet Society (2001). All Rights Reserved. This 1076 document and translations of it may be copied and furnished to 1077 others, and derivative works that comment on or otherwise explain it 1078 or assist in its implementation may be prepared, copied, published 1079 and distributed, in whole or in part, without restriction of any 1080 kind, provided that the above copyright notice and this paragraph 1081 are included on all such copies and derivative works. However, this 1082 document itself may not be modified in any way, such as by removing 1083 the copyright notice or references to the Internet Society or other 1084 Internet organizations, except as needed for the purpose of 1085 developing Internet standards in which case the procedures for 1086 copyrights defined in the Internet Standards process must be 1087 followed, or as required to translate it into languages other than 1088 English. 1090 The limited permissions granted above are perpetual and will not be 1091 revoked by the Internet Society or its successors or assigns. 1093 This document and the information contained herein is provided on an 1094 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1095 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1096 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1097 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1098 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1100 Acknowledgement 1102 Funding for the RFC Editor function is currently provided by the 1103 Internet Society.