1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
|
<pre>Network Working Group L. Martini
Request for Comments: 4446 Cisco Systems Inc.
BCP: 116 April 2006
Category: Best Current Practice
<span class="h1">IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)</span>
Status of This Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document allocates the fixed pseudowire identifier and other
fixed protocol values for protocols that have been defined in the
Pseudo Wire Edge to Edge (PWE3) working group. Detailed IANA
allocation instructions are also included in this document.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-1-2">2</a>
<a href="#section-2">2</a>. Specification of Requirements ...................................<a href="#page-1-2">2</a>
<a href="#section-3">3</a>. IANA Considerations .............................................<a href="#page-1-2">2</a>
<a href="#section-3.1">3.1</a>. Expert Review Directives ...................................<a href="#page-1-2">2</a>
<a href="#section-3.2">3.2</a>. MPLS Pseudowire Type .......................................<a href="#page-1-3">3</a>
<a href="#section-3.3">3.3</a>. Interface Parameters Sub-TLV Type ..........................<a href="#page-1-4">4</a>
<a href="#section-3.4">3.4</a>. Attachment Identifiers .....................................<a href="#page-1-5">5</a>
<a href="#section-3.4.1">3.4.1</a>. Attachment Individual Identifier Type ...............<a href="#page-1-5">5</a>
<a href="#section-3.4.2">3.4.2</a>. Attachment Group Identifier (AGI) Type ..............<a href="#page-1-5">5</a>
<a href="#section-3.5">3.5</a>. Pseudowire Status ..........................................<a href="#page-1-6">6</a>
<a href="#section-3.6">3.6</a>. PW Associated Channel Type .................................<a href="#page-1-6">6</a>
<a href="#section-4">4</a>. Security Considerations .........................................<a href="#page-1-7">7</a>
<a href="#section-5">5</a>. References ......................................................<a href="#page-1-7">7</a>
<a href="#section-5.1">5.1</a>. Normative References .......................................<a href="#page-1-7">7</a>
<a href="#section-5.2">5.2</a>. Informative References .....................................<a href="#page-1-7">7</a>
<span class="grey">Martini Best Current Practice [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-1-2" ></span>
<span class="grey"><a href="./rfc4446">RFC 4446</a> IANA Allocations for PWE3 April 2006</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Most of the new IANA registries and respective IANA-allocation
processes for protocols defined in the PWE3 IETF working group can be
found in this document. The IANA registries defined here are in
general subdivided into three main ranges: a range to be allocated by
IETF consensus according to [<a href="./rfc2434" title="">RFC2434</a>], a range to be allocated by the
expert review process according to [<a href="./rfc2434" title="">RFC2434</a>], and a range to be
allocated on a first come, first served basis that is reserved for
vendor proprietary allocations. Note that vendor proprietary types
MUST NOT be registered for IETF standards or extensions thereof,
whether they are still in development or already completed.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Specification of Requirements</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. IANA Considerations</span>
IANA has created several registries as described in the following
paragraphs. Each of these registries contains numeric values used to
identify data types. In each of these registries, the value of 0 is
reserved and MUST not be used.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Expert Review Directives</span>
Throughout this document, allocation procedures for several
registries call for an expert review process according to [<a href="./rfc2434" title="">RFC2434</a>].
The expert should consider the following points:
* Duplication of code point allocations should be avoided.
* A brief, clear description of the code point allocation
requested should be provided.
* The type allocation requested should be appropriate for the
particular requested value range in the registry.
The expert reviewing the request MUST approve or disapprove the
request within 10 business days from when he or she received the
expert review request.
<span class="grey">Martini Best Current Practice [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-1-3" ></span>
<span class="grey"><a href="./rfc4446">RFC 4446</a> IANA Allocations for PWE3 April 2006</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. MPLS Pseudowire Type</span>
IANA has set up the registry of "MPLS Pseudowire Type". This type
has 15-bit values. PW Type values 1 through 30 are specified in this
document, and PW Type values 31 through 1024 are to be assigned by
IANA, using the "Expert Review" policy defined in [<a href="./rfc2434" title="">RFC2434</a>]. PW Type
values 1025 through 4096 and 32767 are to be allocated using the IETF
consensus policy defined in [<a href="./rfc2434" title="">RFC2434</a>]. PW Type values 4097 through
32766 are reserved for vendor-proprietary extensions and are to be
assigned by IANA, using the "First Come First Served" policy defined
in [<a href="./rfc2434" title="">RFC2434</a>]. A Pseudowire Type description is required for any
assignment from this registry. Additionally, for the vendor-
proprietary extensions range, a citation of a person or company name
is also required. A document reference should also be provided.
Initial Pseudowire Type value allocations are specified below:
PW type Description Reference
===================================================================
0x0001 Frame Relay DLCI ( Martini Mode ) [<a href="#ref-FRAME" title=""Encapsulation Methods for Transport of Frame Relay Over MPLS Networks"">FRAME</a>]
0x0002 ATM AAL5 SDU VCC transport [<a href="#ref-ATM" title=""Encapsulation Methods for Transport of ATM Over MPLS Networks"">ATM</a>]
0x0003 ATM transparent cell transport [<a href="#ref-ATM" title=""Encapsulation Methods for Transport of ATM Over MPLS Networks"">ATM</a>]
0x0004 Ethernet Tagged Mode [<a href="#ref-ETH" title=""Encapsulation Methods for Transport of Ethernet Frames Over MPLS Networks"">ETH</a>]
0x0005 Ethernet [<a href="#ref-ETH" title=""Encapsulation Methods for Transport of Ethernet Frames Over MPLS Networks"">ETH</a>]
0x0006 HDLC [<a href="#ref-PPPHDLC" title=""Encapsulation Methods for Transport of PPP/HDLC Frames Over MPLS Networks"">PPPHDLC</a>]
0x0007 PPP [<a href="#ref-PPPHDLC" title=""Encapsulation Methods for Transport of PPP/HDLC Frames Over MPLS Networks"">PPPHDLC</a>]
0x0008 SONET/SDH Circuit Emulation Service Over MPLS [<a href="#ref-CEP" title=""SONET/SDH Circuit Emulation Service Over Packet (CEP)"">CEP</a>]
0x0009 ATM n-to-one VCC cell transport [<a href="#ref-ATM" title=""Encapsulation Methods for Transport of ATM Over MPLS Networks"">ATM</a>]
0x000A ATM n-to-one VPC cell transport [<a href="#ref-ATM" title=""Encapsulation Methods for Transport of ATM Over MPLS Networks"">ATM</a>]
0x000B IP Layer2 Transport [<a href="./rfc3032" title=""MPLS Label Stack Encoding"">RFC3032</a>]
0x000C ATM one-to-one VCC Cell Mode [<a href="#ref-ATM" title=""Encapsulation Methods for Transport of ATM Over MPLS Networks"">ATM</a>]
0x000D ATM one-to-one VPC Cell Mode [<a href="#ref-ATM" title=""Encapsulation Methods for Transport of ATM Over MPLS Networks"">ATM</a>]
0x000E ATM AAL5 PDU VCC transport [<a href="#ref-ATM" title=""Encapsulation Methods for Transport of ATM Over MPLS Networks"">ATM</a>]
0x000F Frame-Relay Port mode [<a href="#ref-FRAME" title=""Encapsulation Methods for Transport of Frame Relay Over MPLS Networks"">FRAME</a>]
0x0010 SONET/SDH Circuit Emulation over Packet [<a href="#ref-CEP" title=""SONET/SDH Circuit Emulation Service Over Packet (CEP)"">CEP</a>]
0x0011 Structure-agnostic E1 over Packet [<a href="#ref-SAToP" title=""Structure-Agnostic TDM over Packet (SAToP)"">SAToP</a>]
0x0012 Structure-agnostic T1 (DS1) over Packet [<a href="#ref-SAToP" title=""Structure-Agnostic TDM over Packet (SAToP)"">SAToP</a>]
0x0013 Structure-agnostic E3 over Packet [<a href="#ref-SAToP" title=""Structure-Agnostic TDM over Packet (SAToP)"">SAToP</a>]
0x0014 Structure-agnostic T3 (DS3) over Packet [<a href="#ref-SAToP" title=""Structure-Agnostic TDM over Packet (SAToP)"">SAToP</a>]
0x0015 CESoPSN basic mode [<a href="#ref-CESoPSN" title=""Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)"">CESoPSN</a>]
0x0016 TDMoIP AAL1 Mode [<a href="#ref-TDMoIP" title=""TDM over IP"">TDMoIP</a>]
0x0017 CESoPSN TDM with CAS [<a href="#ref-CESoPSN" title=""Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)"">CESoPSN</a>]
0x0018 TDMoIP AAL2 Mode [<a href="#ref-TDMoIP" title=""TDM over IP"">TDMoIP</a>]
0x0019 Frame Relay DLCI [<a href="#ref-FRAME" title=""Encapsulation Methods for Transport of Frame Relay Over MPLS Networks"">FRAME</a>]
<span class="grey">Martini Best Current Practice [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span class="grey"><a href="./rfc4446">RFC 4446</a> IANA Allocations for PWE3 April 2006</span>
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Interface Parameters Sub-TLV Type</span>
IANA has to set up the registry of "Pseudowire Interface Parameter
Sub-TLV types". This type has 8-bit values. Sub-TLV types 1 through
12 are specified in this document. Sub-TLV types 13 through 64 are
to be assigned by IANA, using the "Expert Review" policy defined in
[<a href="./rfc2434" title="">RFC2434</a>]. Sub-TLV types 65 through 127 and 255 are to be allocated
using the IETF consensus policy defined in [<a href="./rfc2434" title="">RFC2434</a>]. Sub-TLV types
values 128 through 254 are reserved for vendor-proprietary extensions
and are to be assigned by IANA, using the "First Come First Served"
policy defined in [<a href="./rfc2434" title="">RFC2434</a>].
Any assignments requested from this registry require a description of
up to 54 characters.
For each allocation, a length field MUST also be specified in one of
the following formats:
- Text as follows:"up to X", where X is a decimal integer.
- Up to 3 different decimal integers.
The text "up to X" means up to and including X.
Additionally, for the vendor-proprietary extensions range, a citation
of a person or company name is also required. A document reference
should also be provided.
Initial Pseudowire Interface Parameter Sub-TLV type allocations are
specified below:
Parameter Length Description Reference
ID
========================================================================
0x01 4 Interface MTU in octets [<a href="#ref-CRTL" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">CRTL</a>]
0x02 4 Maximum Number of concatenated ATM cells [<a href="#ref-ATM" title=""Encapsulation Methods for Transport of ATM Over MPLS Networks"">ATM</a>]
0x03 up to 82 Optional Interface Description string [<a href="#ref-CRTL" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">CRTL</a>][RFC2277]
0x04 4 CEP/TDM Payload Bytes [<a href="#ref-CEP" title=""SONET/SDH Circuit Emulation Service Over Packet (CEP)"">CEP</a>][TDMoIP]
0x05 4 CEP options [<a href="#ref-CEP" title=""SONET/SDH Circuit Emulation Service Over Packet (CEP)"">CEP</a>]
0x06 4 Requested VLAN ID [<a href="#ref-ETH" title=""Encapsulation Methods for Transport of Ethernet Frames Over MPLS Networks"">ETH</a>]
0x07 6 CEP/TDM bit-rate [<a href="#ref-CEP" title=""SONET/SDH Circuit Emulation Service Over Packet (CEP)"">CEP</a>][TDMoIP]
0x08 4 Frame-Relay DLCI Length [<a href="#ref-FRAME" title=""Encapsulation Methods for Transport of Frame Relay Over MPLS Networks"">FRAME</a>]
0x09 4 Fragmentation indicator [<a href="#ref-FRAG" title=""PWE3 Fragmentation and Reassembly"">FRAG</a>]
0x0A 4 FCS retention indicator [<a href="#ref-FCS" title=""PWE3 Frame Check Sequence Retention"">FCS</a>]
0x0B 4/8/12 TDM options [<a href="#ref-TDMoIP" title=""TDM over IP"">TDMoIP</a>]
0x0C 4 VCCV parameter [<a href="#ref-VCCV" title=""Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)"">VCCV</a>]
Note that the Length field is defined as the length of the Sub-TLV,
including the Sub-TLV type and length field itself.
<span class="grey">Martini Best Current Practice [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2-5" ></span>
<span class="grey"><a href="./rfc4446">RFC 4446</a> IANA Allocations for PWE3 April 2006</span>
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Attachment Identifiers</span>
<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>. Attachment Individual Identifier Type</span>
IANA has to set up the registry of "Attachment Individual Identifier
(AII) Type". This type has 8-bit values. AII Type value 1 is
defined in this document. AII Type values 2 through 64 are to be
assigned by IANA, using the "Expert Review" policy defined in
[<a href="./rfc2434" title="">RFC2434</a>]. AII Type values 65 through 127 and 255 are to be
allocated using the IETF consensus policy defined in [<a href="./rfc2434" title="">RFC2434</a>]. AII
types values 128 through 254 are reserved for vendor-proprietary
extensions and are to be assigned by IANA, using the "First Come
First Served" policy defined in [<a href="./rfc2434" title="">RFC2434</a>].
Any assignments requested from this registry require a description of
up to 54 characters.
For each allocation, a length field MUST also be specified as a
decimal integer.
Additionally, for the vendor-proprietary extensions range, a citation
of a person or company name is also required. A document reference
should also be provided.
Initial Attachment Individual Identifier (AII) Type allocations are
specified below:
AII Type Length Description Reference
=====================================================================
0x01 4 A 32 bit unsigned number local [<a href="#ref-SIG" title=""Provisioning, Autodiscovery, and Signaling in L2VPNs"">SIG</a>]
identifier.
<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>. Attachment Group Identifier (AGI) Type</span>
IANA has to set up the registry of "Attachment Group Identifier (AGI)
Type". This type has 8-bit values. AGI Type value 1 is defined in
this document. AGI Type values 2 through 64 are to be assigned by
IANA, using the "Expert Review" policy defined in [<a href="./rfc2434" title="">RFC2434</a>]. AGI
Type values 65 through 127 and 255 are to be allocated using the IETF
consensus policy defined in [<a href="./rfc2434" title="">RFC2434</a>]. AGI type values 128 through
254 are reserved for vendor-proprietary extensions and are to be
assigned by IANA, using the "First Come First Served" policy defined
in [<a href="./rfc2434" title="">RFC2434</a>].
Any assignments requested from this registry require a description of
up to 54 characters.
<span class="grey">Martini Best Current Practice [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2-6" ></span>
<span class="grey"><a href="./rfc4446">RFC 4446</a> IANA Allocations for PWE3 April 2006</span>
For each allocation, a length field MUST also be specified as a
decimal integer.
Additionally, for the vendor-proprietary extensions range, a citation
of a person or company name is also required. A document reference
should also be provided.
Initial Attachment Group Identifier (AGI) Type allocations are
specified below:
AGI Type Length Description Reference
===================================================================
0x01 8 AGI encoded as Route Distinguisher [<a href="#ref-SIG" title=""Provisioning, Autodiscovery, and Signaling in L2VPNs"">SIG</a>]
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Pseudowire Status</span>
IANA has to set up the registry of "Pseudowire Status Codes". These
are bit strings of length 32. Status bits 0 through 4 are defined in
this document. Status bits 5 through 31 are to be assigned by IANA
using the "Expert Review" policy defined in [<a href="./rfc2434" title="">RFC2434</a>].
Any requests for allocation from this registry require a description
of up to 65 characters.
Initial Pseudowire Status Code value allocations are as follows:
Bit Mask Description
====================================================================
0x00000000 - Pseudowire forwarding (clear all failures) [<a href="#ref-CRTL" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">CRTL</a>]
0x00000001 - Pseudowire Not Forwarding [<a href="#ref-CRTL" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">CRTL</a>]
0x00000002 - Local Attachment Circuit (ingress) Receive Fault [<a href="#ref-CRTL" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">CRTL</a>]
0x00000004 - Local Attachment Circuit (egress) Transmit Fault [<a href="#ref-CRTL" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">CRTL</a>]
0x00000008 - Local PSN-facing PW (ingress) Receive Fault [<a href="#ref-CRTL" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">CRTL</a>]
0x00000010 - Local PSN-facing PW (egress) Transmit Fault [<a href="#ref-CRTL" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">CRTL</a>]
For the definition of the "PW Associated Channel Type" please refer
to [<a href="./rfc4385" title=""Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN"">RFC4385</a>].
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a> PW Associated Channel Type</span>
For the definition of the "PW Associated Channel Type", please refer
to [<a href="./rfc4385" title=""Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN"">RFC4385</a>].
<span class="grey">Martini Best Current Practice [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2-7" ></span>
<span class="grey"><a href="./rfc4446">RFC 4446</a> IANA Allocations for PWE3 April 2006</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This document specifies only fixed identifiers, and not the protocols
used to carry the encapsulated packets across the network. Each such
protocol may have its own set of security issues, but those issues
are not affected by the identifiers specified herein.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. References</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Normative References</span>
[<a id="ref-RFC2434">RFC2434</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC 2434</a>,
October 1998.
[<a id="ref-RFC2277">RFC2277</a>] Alvestrand, H., "IETF Policy on Character Sets and
Languages", <a href="https://www.rfc-editor.org/bcp/bcp18">BCP 18</a>, <a href="./rfc2277">RFC 2277</a>, January 1998.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Informative References</span>
[<a id="ref-CRTL">CRTL</a>] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", <a href="./rfc4447">RFC 4447</a>, April 2006.
[<a id="ref-VCCV">VCCV</a>] Nadeau, T. and R. Aggarwal, "Pseudo Wire Virtual Circuit
Connectivity Verification (VCCV)", Work in Progress, August
2005.
[<a id="ref-FRAG">FRAG</a>] Malis, A. and M. Townsley, "PWE3 Fragmentation and
Reassembly", Work in Progress, September 2005.
[<a id="ref-FCS">FCS</a>] Malis, A., Allan, D., and N. Del Regno, "PWE3 Frame Check
Sequence Retention", Work in Progress, September 2005.
[<a id="ref-CEP">CEP</a>] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
"SONET/SDH Circuit Emulation Service Over Packet (CEP)",
Work in Progress.
[<a id="ref-SAToP">SAToP</a>] Vainshtein, A. Ed. and Y. Stein, Ed. "Structure-Agnostic
TDM over Packet (SAToP)", Work in Progress.
[<a id="ref-FRAME">FRAME</a>] Martini, L., Ed. and C. Kawa, "Encapsulation Methods for
Transport of Frame Relay Over MPLS Networks", Work in
Progress.
<span class="grey">Martini Best Current Practice [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2-8" ></span>
<span class="grey"><a href="./rfc4446">RFC 4446</a> IANA Allocations for PWE3 April 2006</span>
[<a id="ref-ATM">ATM</a>] Martini, L., Ed., El-Aawar, N., and M. Bocci, Ed.,
"Encapsulation Methods for Transport of ATM Over MPLS
Networks", Work in Progress.
[<a id="ref-PPPHDLC">PPPHDLC</a>] Martini, L., Rosen, E., Heron, G. and A. Malis,
"Encapsulation Methods for Transport of PPP/HDLC Frames
Over MPLS Networks", Work in Progress.
[<a id="ref-ETH">ETH</a>] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet Frames
Over MPLS Networks", <a href="./rfc4448">RFC 4448</a>, April 2006.
[<a id="ref-CESoPSN">CESoPSN</a>] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
P. Pate, "Structure-aware TDM Circuit Emulation Service
over Packet Switched Network (CESoPSN)", Work in Progress.
[<a id="ref-TDMoIP">TDMoIP</a>] Stein, Y., Shashoua, R., Insler, R., and M. Anavi, "TDM
over IP", Work in Progress, February 2005.
[<a id="ref-RFC3032">RFC3032</a>] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", <a href="./rfc3032">RFC 3032</a>, January 2001.
[<a id="ref-SIG">SIG</a>] Rosen, E., Luo, W., Davie, B., and V. Radoaca,
"Provisioning, Autodiscovery, and Signaling in L2VPNs",
Work in Progress, September 2005.
[<a id="ref-RFC4385">RFC4385</a>] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", <a href="./rfc4385">RFC 4385</a>, February 2006.
Author's Address
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO, 80112
EMail: lmartini@cisco.com
<span class="grey">Martini Best Current Practice [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2-9" ></span>
<span class="grey"><a href="./rfc4446">RFC 4446</a> IANA Allocations for PWE3 April 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Martini Best Current Practice [Page 9]
</pre>
|
