idnits 2.17.1 draft-vainshtein-pwe3-tdm-control-protocol-extensi-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 489. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([PWE3-CONTROL], [PWE3-IANA]), 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 2006) is 6676 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: 'SHAH-PWE3-CONTROL-EXT' is mentioned on line 85, but not defined == Missing Reference: 'CESoPSN' is mentioned on line 357, but not defined == Unused Reference: 'RFC2119' is defined on line 436, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-16 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-09 == Outdated reference: A later version (-10) exists of draft-ietf-pwe3-fragmentation-08 -- No information found for draft-ietf-pwe3-SAToP - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PWE3-SAToP' == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-cesopsn-02 == Outdated reference: A later version (-06) exists of draft-ietf-pwe3-tdmoip-03 Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Vainshtein (Axerra Networks) 3 Internet Draft Y(J) Stein (RAD Data Communications) 5 Expiration Date: 6 January 2006 8 July 2005 10 Control Protocol Extensions for Setup of TDM Pseudowires 12 draft-vainshtein-pwe3-tdm-control-protocol-extensi-04.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware have 18 been or will be disclosed, and any of which he or she becomes aware 19 will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document defines extension to the PWE3 control protocol [PWE3- 39 CONTROL] and PWE3 IANA allocations [PWE3-IANA] required for setup of 40 TDM pseudowires. 42 Control Protocol Extensions for Setup of TDM Pseudowires July 2005 44 TABLE OF CONTENTS 46 1. Introduction......................................................2 47 2. PW FEC for Setup of TDM PWs.......................................2 48 3. Interface Parameters for TDM PWs..................................3 49 3.1. CEP/TDM Payload Bytes (0x04)..................................3 50 3.2. CEP/TDM Bit-Rate (0x07).......................................4 51 3.3. Number of TDMoIP AAL1 cells per packet (0x0D - subject to IANA 52 approval)..........................................................4 53 3.4. TDMoIP AAL1 mode (0x0E - subject to IANA approval)............5 54 3.5. TDMoIP AAL2 Options (0x0F - subject to IANA approval).........5 55 3.6. Fragmentation Indicator (0x09)................................6 56 3.7. TDM Options (0x0B subject to IANA approval)...................6 57 4. Extending CESoPSN Basic NxDS0 Services with CE Application 58 Signaling............................................................8 59 5. LDP Status Codes..................................................9 60 6. IANA Considerations...............................................9 61 7. Security Considerations...........................................9 62 8. Acknowledgements.................................................10 63 9. Normative References.............................................10 64 10. Informative References..........................................10 66 1. Introduction 68 This document defines extension to the PWE3 control protocol [PWE3- 69 CONTROL] and PWE3 IANA allocations [PWE3-IANA] required for setup of 70 TDM pseudowires. 72 Structure-agnostic TDM pseudowires have been specified in [PWE3-SAToP] 73 and structure-aware ones in [PWE3-CESoPSN] and [PWE3-TDMoIP]. 75 [PWE3-CONTROL] defines extensions to LDP [RFC3036] that are required to 76 exchange PW labels for PWs emulating various Layer 2 services 77 (Ethernet, FR, ATM, HDLC etc.). Setup of TDM PWs requires both 78 interpretation of the existing information elements of these extensions 79 and exchange of additional information. 81 Setup of TDM PWs using L2TPv3 will be defined in a separate document. 83 Status of attachment circuits of TDM PWs can be exchanged between the 84 terminating PEs using the mechanism defined in [PWE3-CONTROL] and 85 [SHAH-PWE3-CONTROL-EXT] without any changes. However, usage of these 86 mechanisms with TDM PWs is NOT RECOMMENDED since indication of status 87 of the TDM attachment circuits is carried in-band in the data plane. 88 2. PW FEC for Setup of TDM PWs 90 [PWE3-CONTROL] uses LDP Label Mapping message [RFC3036] for advertising 91 the FEC-to-PW Label binding, and defines two types of PW FEC that can 92 be used for this purpose: 94 1. PWId FEC (FEC 128). This FEC contains: 95 a) PW type 96 b) Control bit (indicates presence of the control word) 97 c) Group ID 98 d) PW ID 99 e) Interface parameters 100 2. Generalized PW FEC (FEC 129). This FEC contains only: 101 a) PW type 102 b) Control bit 103 c) AGI, SAII and TAII that replace the PW ID 105 The Group ID and the Interface parameters are contained in separate 106 TLVs, called the PW Grouping TLV and the Interface Parameters TLV. 108 Both types of PW FEC MAY be used for setup of TDM PWs with appropriate 109 selection of PW types and interface parameters. 111 The PW Types for TDM PWs are allocated in [PWE3-IANA] as follows: 113 o 0x0011 Structure-agnostic E1 over Packet [PWE3-SAToP] 114 o 0x0012 Structure-agnostic T1 (DS1) over Packet [PWE3-SAToP] 115 o 0x0013 Structure-agnostic E3 over Packet [PWE3-SAToP] 116 o 0x0014 Structure-agnostic T3 (DS3) over Packet [PWE3-SAToP] 117 o 0x0015 CESoPSN basic mode [PWE3-CESoPSN] 118 o 0x0016 TDMoIP AAL1 mode [PWE3-TDMoIP] 119 o 0x0017 CESoPSN TDM with CAS [PWE3-CESoPSN] 120 o 0x0018 TDMoIP AAL2 mode [PWE3-TDMoIP] 122 The two endpoints MUST agree on the PW type, as both directions of the 123 PW are required to be of the same type. 125 The Control bit MUST always be set for TDM PWs since all TDM PW 126 encapsulations always use a control word. 128 3. Interface Parameters for TDM PWs 129 3.1. CEP/TDM Payload Bytes (0x04) 131 This parameter is used for setup of all SAToP and CESoPSN PWs (i.e. PW 132 types 0x0011, 0x0012, 0x0013, 0x0014, 0x0015 and 0x0017) with the 133 following semantics: 135 1. The two endpoints of a TDM PW MUST agree on the same value of this 136 parameter for the PW to be set up successfully. 137 2. Presence of this parameter in the PWId FEC or in the Interface 138 Parameters Field TLV is OPTIONAL. If this parameter is omitted, 139 default payload size defined for the corresponding service (see 140 [PWE3-SAToP], [PWE3-CESoPSN]) MUST be assumed 141 3. For structure-agnostic emulation, any value consistent with the MTU 142 of the underlying PSN MAY be specified 144 4. For CESoPSN PWs: 145 a) The specified value P MUST be an integer multiple of N, where N 146 is the number of timeslots in the attachment circuit 147 b) For trunk-specific NxDS0 with CAS: 148 i) (P/N) MUST be an integer factor of the number of frames per 149 corresponding trunk multiframe (i.e. 16 for an E1 trunk and 150 24 of a T1 trunk) 151 ii) The size of the signaling sub-structure is not accounted 152 for in the specified value P. 154 3.2. CEP/TDM Bit-Rate (0x07) 156 This interface parameter represents the bit-rate of the TDM service in 157 multiples of the "basic" 64 Kbit/s rate. Its usage for all types of TDM 158 PWs assumes the following semantics: 160 1. This interface parameter MAY be omitted if the attachment circuit 161 bit-rate can be unambiguously derived from the PW Type (i.e. for 162 structure-agnostic emulation of E1, E3 and T3 circuits). If this 163 value is omitted for the structure-agnostic emulation of T1 PW 164 Type, the basic emulation mode MUST be assumed. 165 2. If present, only the following values MUST be specified for 166 structure-agnostic emulation (see [PWE3-SAToP]: 167 a) Structure-agnostic E1 emulation - 32 168 b) Structure-agnostic T1 emulation: 169 i) MUST be set to 24 in the basic emulation mode 170 ii) MUST be set to 25 for the "Octet-aligned T1" emulation mode 171 c) Structure-agnostic E3 emulation - 535 172 d) Structure-agnostic T3 emulation - 699 173 3. For all kinds of structure-aware emulation, this parameter MUST be 174 set to N where N is the number of DS0 channels in the corresponding 175 attachment circuit. 177 Note: The value 24 does not represent the actual bit-rate of the T1 178 circuit (1,544 Mbit/s) in units of 64 kbit/s. The values mentioned 179 above are used for convenience. 181 3.3. Number of TDMoIP AAL1 cells per packet (0x0D - subject to 182 IANA approval) 184 This parameter MAY be present for TDMoIP AAL1 mode PWs (PW type 0x0016) 185 and specifies the number of 48-byte AAL1 PDUs per MPLS packet. Any 186 values consistent with the MTU of the underlying PSN MAY be specified. 187 If this parameter is not specified it should default to 1 PDU per 188 packet for low bit-rates (CEP/TDM Bit-Rate less than or equal to 32), 189 and to 5 for high bit-rates (CEP/TDM Bit-Rate of 535 or 699). 191 3.4. TDMoIP AAL1 mode (0x0E - subject to IANA approval) 193 This parameter MAY be present for TDMoIP AAL1 mode PWs (PW type 0x0016) 194 and specifies the AAL1 mode. If this parameter is not present, the AAL1 195 mode defaults to "structured". When specified, the values have the 196 following significance: 197 0 unstructured AAL1 198 2 structured AAL1 199 3 structured AAL1 with CAS. 200 The two endpoints MUST agree on the TDMoIP AAL1 mode. 202 3.5. TDMoIP AAL2 Options (0x0F - subject to IANA approval) 204 This parameter MUST be present for TDMoIP AAL2 mode PWs (PW type 205 0x0018) and has the following format: 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | 0x0F | Length | V| ENCODING | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Maximum Duration | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | CID mapping bases | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 The fields in this parameter as defined as follows: 218 V defines the VAD capabilities. Its values have the following 219 significance: 220 0 means that the CID is only switched by signaling 221 1 means that voice activity detection is employed 222 3 means this channel is always active. In particular, this channel 223 may be used for timing recovery. 225 Encoding specifies native signal processing performed on the payload. 226 When no native signal processing is performed (i.e. G.711 encoding) 227 this field MUST be zero. 229 Maximum Duration specifies the maximum time allowed for filling an AAL2 230 PDU, in units of 125 microseconds. For unencoded 64 kbps channels this 231 numerically equals the maximum number of bytes per PDU, and MUST be 232 less than 64. For other encoding parameters, larger values may be 233 attained. 235 CID mapping bases is an OPTIONAL parameter, its existence and length 236 determined by the length field. If the mapping of AAL2 CID values to 237 physical interface and time slot is statically configured, or if AAL2 238 switching [Q.2630.1] is employed, this parameter MUST NOT appear. When 239 it is present, and the channels belong to N physical interfaces (i.e. N 240 E1s or T1s), it MUST be N bytes in length. Each byte represents a 241 number to be subtracted from the CID to get the timeslot number for 242 each physical interface. For example, if the CID mapping bases 243 parameter consists of the bytes 20 and 60, this signifies that timeslot 244 1 of trunk 1 corresponds to CID 21 and timeslot 1 of trunk 2 is called 245 61. 247 3.6. Fragmentation Indicator (0x09) 249 This interface parameter is specified in [PWE3-IANA] and its usage is 250 explained in [PWE3-FRAG]. It MUST be omitted in the FEC of all TDM PWs 251 excluding trunk-specific NxDS0 services with CAS using the CESoPSN 252 encapsulation. In case of these services, it MUST be present in the PW 253 FEC if the payload size specified value P differs from Nx(number of 254 frames per trunk multiframe). 256 3.7. TDM Options (0x0B subject to IANA approval) 258 This is a new interface parameter. Its Interface Parameter ID has to be 259 assigned by IANA, and its format is shown in Fig. 1 below: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Parameter ID | Length |R|D|F|X|SP |CAS| RSVD-1 | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 |0| PT | RSVD-2 | FREQ | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | SSRC | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 1. Format of the TDM Options Interface Parameter 273 The fields shown in this diagram are used as follows: 275 Parameter ID Identifies the TDM PW Options interface parameter, 276 value TBA by IANA 277 Length 4, 8 or 12 (see below) 278 R The RTP Header Usage bit: if set, indicates that 279 the PW endpoint distributing this FEC expects to 280 receive RTP header in the encapsulation. RTP header 281 will be used only if both endpoints expect to 282 receive it. If this bit is cleared, Length MUST be 283 set to 4, otherwise it MUST be either 8 or 12 (see 284 below). If the peer PW end point cannot meet this 285 requirement, the Label Mapping message containing 286 the FEC in question MUST be rejected with the 287 appropriate status code (see Section 4 below). 288 D The Dynamic Timestamping Mode bit: if set, 289 indicates that the PW endpoint distributing this 290 FEC expects the peer to use Differential 291 timestamping mode in the packets sent to it. If the 292 peer PW end point cannot meet this requirement, the 293 Label Mapping message containing the FEC in 294 question MUST be rejected with the appropriate 295 status code (see Section 4 below). 296 F, X Reserved for future extensions. MUST be cleared by 297 when distributed and MUST be ignored upon reception 298 SP Encodes support for the CESoPSN signaling packets 299 (see [CESoPSN]): 300 o '00' for PWs that do not use signaling packets 301 o '01' for CESoPSN PWs carrying TDM data packets 302 and expecting CE application signaling packets 303 in a separate PW 304 o '10' for a PW carrying CE application signaling 305 packets with the data packets in a separate PW 306 o '11' - for CESoPSN PWs carrying TDM data and CE 307 application signaling on the same PW 308 CAS MUST be cleared for all types of TDM PWs excluding 309 trunk-specific NxDS0 services with CAS. For these 310 services it encodes the trunk framing like 311 following: 312 o '01' - an E1 trunk 313 o '10' - a T1/ESF trunk 314 o '11' - a T1 SF trunk 315 RSVD-1 and RSVD-2 Reserved bits, MUST be set to 0 by the PW endpoint 316 distributing this FEC and MUST be ignored by the 317 receiver 318 PT Indicates the value of Payload Type in the RTP 319 header expected by the PW endpoint distributing 320 this FEC. Value 0 means that PT value check will 321 not be used for detecting malformed packets 322 FREQ Frequency of timestamping clock in units of 8 kHz 323 SSRC Indicates the value of SSRC ID in the RTP header 324 expected by the PW endpoint distributing this FEC. 325 Value 0 means that SSRC ID value check will not be 326 used for detecting misconnections. Alternatively, 327 Length can be set to 8 in this case. 329 Notes: 331 1. This interface parameter MAY be omitted in the following cases: 332 a) SAToP PWs that do not use RTP header [PWE3-SAToP] 333 b) Basic CESoPSN NxDS0 services without CE application signaling 334 [PWE3-CESoPSN] 335 c) TDMoIP AAL1 mode 0 or 2 PWs that do not use RTP. 336 d) TDMoIP AAL2 PWs that do not relay CAS signaling and do not use 337 RTP. 338 2. This interface parameter MUST be present in the following cases: 339 a) All TDM PWs that use RTP header 340 b) CESoPSN PWs that carry basic NxDS0 services and use CESoPSN 341 signaling packets to carry CE application signaling. This case 342 is discussed in detail in Section 4 below 343 c) CESoPSN PWs that carry trunk-specific NxDS0 services with CAS 344 d) TDMoIP AAL1 mode 1 PWs 345 e) TDMoIP AAL2 PWs that relay CAS signaling. 346 3. If RTP header and Differential timestamping mode are used, the 347 value of the Length field MUST be set to 8 or 12 in order to 348 include at least the Timestamping Clock Frequency field in the 349 value 350 4. A TDM PW encapsulation MUST either use or not use RTP in both 351 directions. However, it is possible to use Differential 352 timestamping mode in just one direction of the PW. 354 4. Extending CESoPSN Basic NxDS0 Services with CE Application 355 Signaling 357 [CESoPSN] defines that basic NxDS0 services can be extended to carry 358 also CE application signaling (e.g., CAS) in separate signaling packets 359 carried in a separate PW. 361 The following rules define setup of matching pairs of CESoPSN PWs using 362 the PW Id FEC and the extensions defined above: 364 1. The value of PW ID for the CESoPSN PW carrying TDM data packets 365 MUST be even 366 2. The value of PW ID for the CESoPSN PW carrying CE application 367 signaling MUST be the next odd value for the (even) value of PW ID 368 for the CESoPSN PW carrying TDM data packets 369 3. The two PWs MUST: 370 a) Have the same PW Type 371 b) Have the same values of all the Interface Parameters with the 372 exception of the code point in the SP field of the TDM Options 373 parameter. 374 i) The PWId FEC of the PW carrying TDM data packets must be 375 marked with SP bits set to '01' in this field 376 ii) The PWId FEC of the PW carrying CE signaling packets must 377 be marked with SP bits set to '10' in this field. 379 If only one of the two PWs required to carry a CESoPSN basic NxDS0 380 service and associated CE signaling packets has been established and 381 the other one failed, the established PW MUST be torn down. 383 Setup of CESoPSN PWs with CE application signaling using the 384 Generalized PW FEC is left for further study. 386 5. LDP Status Codes 388 In addition to the status codes defined in section 5.3 of [PWE3- 389 CONTROL], the following status codes defined in [PWE3-IANA] MUST be 390 used to indicate the reason of failure to establish a TDM PW: 392 1. Incompatible bit rate: 393 a) In the case of mismatch of T1 encapsulation modes (basic vs. 394 octet-aligned) 395 b) In case of mismatch in the number of timeslots for NxDS0 basic 396 services or trunk-specific NxDS0 services with CAS 397 2. CEP/TDM mis-configuration: 398 a) In the case of mismatch in the desired usage of RTP header 399 b) In the case of mismatch of the desired timestamping clock 400 frequency 401 c) In the case of mismatch of expected signaling packets behavior 402 for basic CESoPSN NxDS0 services extended to carry CE 403 application signaling in separate signaling packets 404 d) In the case of trunk-specific NxDS0 services with CAS if the 405 framing types of the trunks are different 406 e) In the case of TDMoIP AAL1 PWs with different AAL1 modes 407 specified by the end points 409 In cases 2a, 2b, 2c and 2e above, the user MAY reconfigure the end 410 points and attempt to setup the PW once again. 412 In the case 2d the failure is fatal. 414 Note that setting of the Control bit (see section 2 above) to zero MUST 415 result in an LDP status of "Illegal C-Bit". 417 6. IANA Considerations 419 Many of the IANA assignments required by this draft are also listed in 420 [PWE3-IANA]. PW type 0x0018 is redefined here as compared to section 421 2.1 of [PWE3-IANA], and needs to be redefined there in the next 422 version. Assignments in sections 3.3 through 3.5 are required for three 423 additional interface parameters. 425 7. Security Considerations 427 This draft does not have any additional impact on security of PWs above 428 that of basic LDP setup of PWs. 430 8. Acknowledgements 432 AV thanks Sharon Galtzur for reviewing this text. 434 9. Normative References 436 [RFC2119] S. Bradner, Key Words in RFCs to Indicate Requirement Levels, 437 RFC 2119, IETF, 1997 439 [RFC3036] L. Andersson et al, LDP Specification, RFC 3036, IETF, 2001 441 [PWE3-CONTROL] L. Martini et al, Pseudowire Setup and Maintenance using 442 LDP, Work in progress, March 2005, draft-ietf-pwe3-control-protocol- 443 16.txt 445 [PWE3-IANA] L. Martini, M. Townsley, IANA Allocations for pseudo Wire 446 Edge to Edge Emulation (PWE3), Work in progress, April 2005, draft- 447 ietf-pwe3-iana-allocation-09.txt 449 [PWE3-FRAG] A. Malis, M. Townsley, PWE3 Fragmentation and Reassembly, 450 Work in progress, February 2005, draft-ietf-pwe3-fragmentation-08.txt 452 [PWE3-SAToP] A. Vainshtein, Y. Stein, Structure-Agnostic TDM over 453 Packet (SAToP), Work in Progress, December 2003, draft-ietf-pwe3-SAToP- 454 01.txt 456 10. Informative References 458 [PWE3-CESoPSN] A. Vainshtein et al, Structure-aware TDM Circuit 459 Emulation Service over Packet Switched Network (CESoPSN), Work in 460 progress, January 2005, draft-ietf-pwe3-cesopsn-02.txt 462 [PWE3-TDMoIP] Y(J) Stein et al, TDM over IP, Work in progress, draft- 463 ietf-pwe3-tdmoip-03.txt, Feb. 2005. 465 [Q.2630.1] ITU-T Recommendation Q.2630.1, December 1999, AAL type 2 466 signalling protocol - Capability set 1 467 Intellectual Property Statement 469 The IETF takes no position regarding the validity or scope of any 470 Intellectual Property Rights or other rights that might be claimed to 471 pertain to the implementation or use of the technology described in 472 this document or the extent to which any license under such rights 473 might or might not be available; nor does it represent that it has made 474 any independent effort to identify any such rights. Information on the 475 procedures with respect to rights in RFC documents can be found in BCP 476 78 and BCP 79. 478 Copies of IPR disclosures made to the IETF Secretariat and any 479 assurances of licenses to be made available, or the result of an 480 attempt made to obtain a general license or permission for the use 481 of such proprietary rights by implementers or users of this 482 specification can be obtained from the IETF on-line IPR repository 483 at http://www.ietf.org/ipr. 485 The IETF invites any interested party to bring to its attention any 486 copyrights, patents or patent applications, or other proprietary 487 rights that may cover technology that may be required to implement 488 this standard. Please address the information to the IETF at 489 ietf-ipr@ietf.org. 491 Authors' Addresses 493 Alexander ("Sasha") Vainshtein 494 Axerra Networks 495 24 Raoul Wallenberg St., 496 Tel Aviv 69719, Israel 497 email: sasha@axerra.com 499 Yaakov (Jonathan) Stein 500 RAD Data Communications 501 24 Raoul Wallenberg St., Bldg C 502 Tel Aviv 69719 503 ISRAEL 505 Phone: +972 3 645-5389 506 Email: yaakov_s@rad.com 508 Copyright (C) The Internet Society (2005). 510 This document is subject to the rights, licenses and restrictions 511 contained in BCP 78, and except as set forth therein, the authors 512 retain all their rights. 514 This document and the information contained herein are provided on an 515 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 516 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 517 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 518 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 519 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 520 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 522 Acknowledgement 524 Funding for the RFC Editor function is currently provided by the 525 Internet Society.