idnits 2.17.1 draft-bryskin-ccamp-gmpls-ason-lexicography-01.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 3667, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 452. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 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 (February 2005) is 7003 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Duplicate reference: RFC3471, mentioned in 'RFC3473', was also mentioned in 'RFC3471'. Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Igor Bryskin 2 Category: Informational Consultant 4 Expires: July 2005 Adrian Farrel 5 Old Dog Consulting 7 February 2005 9 A Lexicography for the Interpretation of Generalized Multiprotocol 10 Label Switching (GMPLS) Terminology within The Context of the 11 ITU-T's Automatically Switched Optical Network (ASON) Architecture 13 draft-bryskin-ccamp-gmpls-ason-lexicography-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, I certify that any applicable 18 patent or other IPR claims of which I am aware have been disclosed, 19 or will be disclosed, and any of which I become aware will be 20 disclosed, in accordance with RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be 35 accessed at http://www.ietf.org/shadow.html. 37 Abstract 39 Generalized Multiprotocol Label Switching (GMPLS) has been developed 40 by the IETF to facilitate the establishment of Label Switched Paths 41 (LSPs) in a variety of physical technologies and across several 42 architectural models. The ITU-T has specified an architecture for 43 the management of Automatically Switched Optical Networks (ASON). 45 This document provides a lexicography for the interpretation of GMPLS 46 terminology within the context of the ASON architecture. 48 It is important to note that GMPLS is applicable in a far wider set 49 of contexts than just ASON. Thus the definitions presented in this 50 document do not provide exclusive or complete interpretations of the 51 GMPLS concepts. The intention of this document is simply to allow the 52 GMPLS terms to be applied within the ASON context. 54 1. Introduction 56 Generalized Multiprotocol Label Switching (GMPLS) has been developed 57 by the IETF to facilitate the establishment of Label Switched Paths 58 (LSPs) in a variety of physical technologies such as Packet Switching 59 Capable (PSC), Layer Two Switching Capable (L2SC), Time Division 60 Multiplexing (TDM), Lambda Switching Capable (LSC). and Fiber 61 Switching Capable (FSC). 63 GMPLS is deliberately specified to allow it to be applicable in 64 several key architectures including the Integrated Model, the Overlay 65 Model, and the Augmented Model. More information on these 66 architectural models and on GMPLS can be found in [RFC3945]. 68 The ITU-T has specified an architecture for the management of 69 Automatically Switched Optical Networks (ASON). This architecture 70 forms the basis of many recommendations within the ITU-T. 72 Because the GMPLS and ASON architectures were developed by different 73 people in different standards bodies, and because the architectures 74 have very different historic backgrounds (the Internet, and telephone 75 and transport networks respectively), the terminology used is 76 different. In order to demonstrate that GMPLS is a suitable 77 technology to satisfy the requirements of the ASON architecture it is 78 necessary to examine the terminology and provide a mapping between 79 GMPLS and ASON terms. 81 This document provides a lexicography for the interpretation of GMPLS 82 terminology within the context of the ASON architecture. It does not 83 provide wider definitions of the GMPLS terms which can already be 84 found in existing RFCs. Thus the definitions presented in this 85 document do not provide exclusive or complete interpretations of the 86 GMPLS concepts. The intention of this document is simply to allow the 87 GMPLS terms to be applied within the ASON context. 89 Note that the limitation of GMPLS to the ASON architecture in this 90 document is in no sense intented to imply that GMPLS applicability is 91 limited to the ASON architecture, nor that the ASON model is 92 preferable to any other model that can be supported by GMPLS. 94 2. Terminology Sources 96 2.1. GMPLS Terminology Sources 98 GMPLS Terminology is principally defined in [RFC3945]. Other 99 documents provide further key definitions including [GMPLS-RTG], 100 [BUNDLE], [LSP-HIER] and [LMP]. 102 The reader should be familiar with these other documents before 103 attempting to use this document to provide a mapping to between GMPLS 104 and ASON. 106 For details of GMPLS signaling please refer to [RFC3471] and 107 [RFC3473]. For details of GMPLS routing, please refer to [GMPLS-OSPF] 108 and [GMPLS-ISIS]. 110 2.2. ASON Terminology Sources 112 The ASON architecture is specified in ITU-T Recommendation G.8080 113 [G-8080]. This is developed from generic functional architectures and 114 requirements specified in [G-805], [G-807] and [G-872]. 116 The reader must be familiar with these documents before attempting to 117 apply the lexicography set out here. 119 2.3. Common Terminology Sources 121 The work in this document builds on the shared view of ASON 122 requirements and requirements expressed in [ASON-SIG], [ASON-RTG] and 123 [TRANSPORT-LMP]. 125 3. Lexicography 127 3.1. Resources 129 Non-PSC resource [Data Plane] is a channel of certain bandwidth that 130 could be allocated in a network data plane of a particular 131 technology for the purpose of user traffic delivery. Examples of 132 non-PSC resources are timeslots, lambda channels, etc. 134 PSC resource [Data Plane] is an abstraction hiding means related to 135 delivery of traffic with particular parameters (most importantly, 136 bandwidth) with particular QoS over PSC media. Examples of PSC 137 resources are forwarding queues, schedulers, etc. 139 Layer Resource (Resource) [Data Plane]. A non-PSC data plane 140 technology may yield resources in different network layers. For 141 example, some TDM devices can operate with VC-12 timeslots, some 142 with VC-4 timeslots and some with VC4-4c timeslots. There are also 143 multiple layers of PSC resources (i.e. one per label in the label 144 stack). Therefore, we define layer resource (or simply resource) 145 irrespective of underlying data plane technology as a basic data 146 plane construct. All other definitions provided in this memo are 147 tightly bound to the resource. Examples of resources are: PSC1, 148 PSC4, ATM VP, ATM VC, Ethernet, VC-12, VC-4, Lambda 10G, Lambda 149 40G. Each resource type is assigned with a number indicating its 150 position in the resource hierarchy - the lower this number the 151 coarser is the granularity of the resource. For instance, the 152 resource type of VC-4 is lower than one of an VC-12 but higher than 153 the resource type of a 2.5G lambda. 155 ITU-T terms for resource: 156 - Connection point (cp) in the context of link discovery; 157 - Link connection in the context of routing, path computation and 158 signaling. 160 3.2. Labels 162 Label [Control Plane] is an abstraction that represents a resource in 163 the control plane. 165 The ITU term for label is sub network point (snp). 167 3.3. Ports 169 Unidirectional data port [Data Plane] is a set of resources of a 170 particular layer that belong to the same transport node and could 171 be allocated for transfer of traffic in this layer to the same 172 neighbor in the same direction. 174 In ITU-T terminology a unidirectional data port is a collection of 175 the same client layer connection points supported by a single trail 176 termination (access point). 178 Bidirectional data port [Data Plane] is an association of two 179 unidirectional data ports of a particular layer that belong to the 180 same transport node and could be used for transfer of traffic in 181 this layer to/from the same neighbor in both directions. 183 3.4. Links 185 Unidirectional data link [Data Plane] is an association of two 186 unidirectional data ports of a particular layer belonging to two 187 transport nodes adjacent in this layer that could be used for 188 transfer of traffic between the two transport nodes in one 189 direction. 191 The ITU term for a unidirecitonal data link is unidirectional link. 193 Bidirectional data link [Data Plane] is an association of two 194 bidirectional data ports of a particular layer belonging to two 195 transport nodes adjacent in this layer that could be used for 196 transfer of traffic between the two transport nodes in both 197 directions. 199 The ITU term for a bidirectional data link is bidirectional link. 201 In the ITU ASON architecture a unidirectional/bidirectional data link 202 is supported by a single unidirectional/bidirectional trail 204 3.5. Connections 206 Unidirectional connection (LSP) [Data Plane] is a single resource or 207 a set of cross-connected resources of a particular layer that could 208 deliver traffic in this ayer between a pair of transport nodes in 209 one direction 211 Bidirectional connection (LSP) [Data Plane] is an association of two 212 unidirectional connections that could simultaneously deliver 213 traffic in a particular layer between a pair of transport nodes in 214 opposite directions. 216 In the context of GMPLS both unidirectional constituents of a 217 bidirectional connection (LSP) take identical paths in terms of TE 218 links and could be provisioned concurrently. 220 The ITU term for a connection is connection. 222 The ITU term for a connection end is connection point (cp). 224 Connection (LSP) segment [Data Plane] is a single resource or a set 225 of cross-connected resources that constitutes a segment of a 226 connection. 228 The ITU term for a connection segment is connection. 230 The ITU does not distinguish between connection and connection 231 segment. 233 3.6. Layers 235 Layer [Data Plane] is a complete set of resources of the same type 236 that could be used for establishing a connection or used for 237 connectionless data delivery. 239 The ITU term is layer network. 241 Note. In GMPLS, the existence of non-blocking switching function in a 242 transport node in a particular layer is inferred from advertising of 243 TE link ends of this layer that belong to this transport node, while 244 in ITU-T the switching function is modeled explicitly as subnetwork. 246 3.7. Switching Capability and Adaptation 248 Switching capability [Data Plane] is an ability of a transport node 249 to cross-connect resources of a particular layer. It could be also 250 defined as the node's ability to be part of connections in a 251 particular layer. 253 Adaptation capability [Data Plane] is an ability of a transport node 254 to use a resource of particular (usually, but not necessarily 255 lower) layer as a data port of a different (usually, but not 256 necessarily higher) layer. It could be also defined as the node's 257 ability to use a connection provisioned in a particular layer as a 258 data link in a different layer. In the PSC environment adaptation 259 usually involves data encapsulation and/or multiplexing techniques 260 at connection source, and decapsulation or/and demultiplexing at 261 connection destination. 263 In the ITU ASON architecture switching capability is modeled as a 264 matrix, and adaptation capability is modeled by the combination of 265 termination and adaptation functions accessible from a particular 266 link. 268 3.8. TE Links 270 TE link end [Control Plane] is a grouping for the purpose of 271 advertising and routing of labels representing resources of a 272 particular layer. 274 The ITU term for a TE link end is snp pool (snpp). 276 Such a grouping allows for decoupling of path selection from resource 277 assignment. Specifically, a path could be selected in a centralized 278 way in terms of TE link ends, while the resource assignment (resource 279 reservation and label allocation) could be performed in a distributed 280 way during the connection setup. A TE link end may, but does not need 281 to, reflect a data port in the data plane. A TE link end is 282 associated with exactly one switching capability or, in other words, 283 with exactly one layer. 285 TE link [Control Plane] is a grouping of two TE link ends associated 286 with two neighboring transport nodes (that is, directly 287 interconnected by one or more data links) in a particular layer. 289 The ITU term for a TE link is snpp link. 291 TE link end advertising [Control Plane]. A routing controller 292 managing a particular transport node advertises local TE link ends. 293 Any routing controller in the TE domain makes a TE link available 294 for its local path computation if it receives consistent 295 advertisements of both TE link ends. Strictly speaking, there is no 296 such a thing as TE link advertising - only TE link end advertising. 297 TE link end advertising may contain information about multiple 298 switching capabilities. This, however, should not be interpreted as 299 advertising of a multi-layer TE link end, rather, as joint 300 advertisement of ends of multiple parallel TE links, each 301 representing resources in separate layers. The advertisement may 302 contain attributes shared by all links in the group (examples: 303 protection capabilities, SRLGs, etc), separate information related 304 to each link (examples: switching capability, data encoding, 305 unreserved bandwidth, etc) as well as information related to 306 inter-layer relationships of the advertised resources (example: 307 adaptation capabilities) should the control plane decide to use 308 them as termination of higher layer TE links. These higher layer TE 309 links, however, are not real yet - they are abstract/virtual until 310 the underlying connections are established and separate Forwarding 311 Adjacency (see below) TE links are advertised. 313 Forwarding Adjacency (FA) [Control Plane] is a TE link that 314 represents in the control plane a dynamically provisioned 315 connection in a particular layer used as a data link in the same 316 layer (via splicing) or a different layer (via adaptation). An FA 317 is advertised in the same way as a TE link - that is, by 318 advertising and synchronizing both FA's ends. An FA is advertised 319 using the same or different instance of TE routing protocol as was 320 used for advertising of TE links that were selected as a path for 321 the connection. 323 Stitching Forwarding Adjacency (Stitching FA) [Control Plane] is a 324 special case of FA when it is associated with and advertised for 325 the same layer as the underlying connection 327 Stitching [Control Plane] is a control plane operation that enables 328 using a connection in a particular layer as a TE link in the same 329 layer. 331 3.9. Component Links and Bundles 333 Component link end [Control Plane] is a grouping of labels 334 representing resources of a particularlayer that is not advertised 335 by TE link advertising. Component link ends may be discovered 336 through means other than TE routing protocols (LMP, local 337 configuration, management plane automated tools, etc.). In all 338 other respects, a component link end is equivalent to a TE link 339 end. 341 Component link end [Control Plane] is a grouping of labels 342 representing resources of a particular layer that is not advertised 343 by TE link advertising. In all other respects, a component link end 344 is equivalent to a TE link end. 346 Component link [Control Plane] is a grouping of two or more component 347 link ends associated with neighboring transport nodes (that is, 348 directly interconnected by one or more data links) in a particular 349 layer. Component links are equivalent to TE links except that the 350 link ends are not advertised. 352 TE bundle [Control Plane] is an association of several parallel (that 353 is, connecting the same pair of transport nodes) component links 354 whose attributes are identical or whose differences sufficiently 355 negligible that the TE domain can view the entire association as a 356 single TE link. A TE bundle is advertised in the same way as a TE 357 link, that is, by representing the associated component link ends 358 as a single TE link end (TE bundle end) which is advertised. 360 3.10. Regions 362 TE region [Control Plane] is an association of all TE links and 363 bundles pertinent to a particular switching capability. A TE region 364 represents exactly one data plane layer (not a data plane 365 technology). Examples of regions are: PSC1, PSC4, ATM VP, ATM VC, 366 Ethernet, VC4, VC4-4c, Lambda 10G, Lambda 40G. 368 4. Guidance on the Application of this Lexicography 370 As discussed in the introduction to this document, this lexicography 371 is intended to bring the concepts and terms associated with GMPLS 372 into the context of the ITU's ASON architecture. Thus, it should help 373 those familiar with ASON to see how they may use the features and 374 functions of GMPLS in order to meet the requirements of an ASON 375 system. For example, a service provider wishing to establish a 376 protected end-to-end service, might read [SEG-PROT] and [E2E-PROT] 377 and wish to understand how the GMPLS terms used relate to the ASON 378 architecture so that he can confirm that he will satisfy his 379 requirements. 381 This document is not a substitute for obtaining a clear understanding 382 of GMPLS. It should not be assumed that a deep knowledge of the ASON 383 architecture combined with this document will allow the reader to 384 comprehend GMPLS. Rather, this lexicography will enable a reader who 385 is familiar with the ASON architecture to make a rapid transition to 386 GMPLS within the ASON context. 388 This lexicography should not be used in order to obtain or derive 389 definitive definitions of GMPLS terms because GMPLS is applicable in 390 a wider context than just the ASON architecture. To obtain 391 definitions of GMPLS terms that are applicable across all GMPLS 392 architectural models, the reader should refer to the RFCs listed in 393 the references sections of this document. [RFC3945] provides an 394 overview of the GMPLS architecture and should be read first. 396 5. IANA Considerations 398 This informational document defines no new code points and requires 399 no action by IANA. 401 6. Management Considerations 403 Both GMPLS and ASON networks require management. Both GMPLS and ASON 404 specifications include considerable efforts to provide operator 405 control and monitoring, as well as OAM functionality. 407 These concepts are, however, out of scope of this document. 409 7. Security Considerations 411 Security is also a significant requirement of both GMPLS and ASON 412 architectures. 414 Again, however, this informational document is intended only to 415 provide a lexicography, and the security concerns are, therefore, out 416 of scope. 418 8. Acknowledgements 420 The authors would like to thank participants in the IETF's CCAMP 421 working group and the ITU-T's Study Group 15 for their help in 422 producing this document. In particular, all those who attended the 423 Study Group 15 Question 14 Interim Meeting in Holmdel, New Jersey 424 during January 2005. 426 Many thanks to Ichiro Inoue of NTT for his useful review and input, 427 and to Scott Brim and Dimitri Papadimitriou for lengthy and 428 constructive discussions. 430 9. Intellectual Property Consideration 432 The IETF takes no position regarding the validity or scope of any 433 Intellectual Property Rights or other rights that might be claimed to 434 pertain to the implementation or use of the technology described in 435 this document or the extent to which any license under such rights 436 might or might not be available; nor does it represent that it has 437 made any independent effort to identify any such rights. Information 438 on the procedures with respect to rights in RFC documents can be 439 found in BCP 78 and BCP 79. 441 Copies of IPR disclosures made to the IETF Secretariat and any 442 assurances of licenses to be made available, or the result of an 443 attempt made to obtain a general license or permission for the use of 444 such proprietary rights by implementers or users of this 445 specification can be obtained from the IETF on-line IPR repository at 446 http://www.ietf.org/ipr. 448 The IETF invites any interested party to bring to its attention any 449 copyrights, patents or patent applications, or other proprietary 450 rights that may cover technology that may be required to implement 451 this standard. Please address the information to the IETF at ietf- 452 ipr@ietf.org. 454 10. Normative References 456 [RFC3945] E. Mannie (Ed.). "Generalized Multi-Protocol Label 457 Switching (GMPLS) Architecture", RFC 3945, October 458 2004. 460 [GMPLS-RTG] Kompella, K. and Rekhter, Y., "Routing Extensions in 461 Support of Generalized Multi-Protocol Label 462 Switching", , work 463 in progress. 465 [BUNDLE] Kompella, K., Rekhter, Y., and Berger, L., "Link 466 Bundling in MPLS Traffic Engineering", 467 , work in progress. 469 [LSP-HIER] Kompella, K. and Rekhter, Y., "LSP Hierarchy with 470 Generalized MPLS TE", 471 , work in progress. 473 [LMP] J. Lang (Ed.), "Link Management Protocol (LMP)", 474 , work in progress. 476 11. Informational References 478 [RFC3471] L. Berger (Ed.), "Generalized Multi-Protocol Label 479 Switching (GMPLS) Signaling Functional Description", 480 RFC 3471, January 2003. 482 [RFC3473] L. Berger (Ed.), "Generalized Multi-Protocol Label 483 Switching (GMPLS) Signaling Resource ReserVation 484 Protocol-Traffic Engineering (RSVP-TE) Extensions", 485 RFC 3471, January 2003. 487 [GMPLS-OSPF] Kompella, K., and Rekhter, Y. (Ed.), "OSPF 488 Extensions in Support of Generalized MPLS", 489 , work in 490 progress. 492 [GMPLS-ISIS] Kompella, K., and Rekhter, Y. (Ed.), "IS-IS 493 Extensions in Support of Generalized MPLS", 494 , work in 495 progress. 497 [ASON-SIG] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., 498 and Ong, L., "Requirements for Generalized MPLS 499 (GMPLS) Signaling Usage and Extensions for 500 Automatically Switched Optical Network (ASON)", 501 , work in 502 progress. 504 [ASON-RTG] D. Brungard (Ed.), "Requirements for Generalized 505 MPLS (GMPLS) Routing for Automatically Switched 506 Optical Network (ASON)", 507 , work in 508 progress. 510 [TRANSPORT-LMP] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J., 511 Papadimitriou, D., "A Transport Network View of LMP" 512 , work in progress. 514 [E2E-PROT] Lang, J., Rekhter, Y., and Papadimitriou, D. (Eds.), 515 "RSVP-TE Extensions in support of End-to-End 516 Generalized Multi-Protocol Label Switching 517 (GMPLS)-based Recovery", 518 , 519 work in progress. 521 [SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D., and 522 Farrel, A., "GMPLS Based Segment Recovery", 523 , work in 524 progress. 526 For information on the availability of the following documents, 527 please see http://www.itu.int. 529 [G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for 530 the automatically switched optical network (ASON). 532 [G-805] ITU-T Recommendation G.805 (2000), Generic 533 functional architecture of transport networks. 535 [G-807] ITU-T Recommendation G.807/Y.1302 (2001), 536 Requirements for the automatic switched transport 537 network (ASTN). 539 [G-872] ITU-T Recommendation G.872 (2001), Architecture of 540 optical transport networks. 542 12. Authors' Addresses 544 Igor Bryskin 545 Independent Consultant 546 EMail: i_bryskin@yahoo.com 548 Adrian Farrel 549 Old Dog Consulting 550 Phone: +44 (0) 1978 860944 551 EMail: adrian@olddog.co.uk 553 13. Disclaimer of Validity 555 This document and the information contained herein are provided on an 556 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 557 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 558 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 559 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 560 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 563 14. Full Copyright Statement 565 Copyright (C) The Internet Society (2005). This document is subject 566 to the rights, licenses and restrictions contained in BCP 78, and 567 except as set forth therein, the authors retain all their rights.