From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5003.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc5003.txt (limited to 'doc/rfc/rfc5003.txt') diff --git a/doc/rfc/rfc5003.txt b/doc/rfc/rfc5003.txt new file mode 100644 index 0000000..61446e6 --- /dev/null +++ b/doc/rfc/rfc5003.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group C. Metz +Request for Comments: 5003 L. Martini +Category: Standards Track Cisco Systems Inc. + F. Balus + Alcatel-Lucent + J. Sugimoto + Nortel Networks + September 2007 + + + Attachment Individual Identifier (AII) Types for Aggregation + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The signaling protocols used to establish point-to-point pseudowires + include type-length-value (TLV) fields that identify pseudowire + endpoints called attachment individual identifiers (AIIs). This + document defines AII structures in the form of new AII TLV fields + that support AII aggregation for improved scalability and Virtual + Private Network (VPN) auto-discovery. It is envisioned that this + would be useful in large inter-domain virtual private wire service + networks where pseudowires are established between selected local and + remote provider edge (PE) nodes based on customer need. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Specification of Requirements ...................................3 + 3. Structure for the New AII Type ..................................3 + 3.1. AII Type 1 .................................................3 + 3.2. AII Type 2 .................................................3 + 4. IANA Considerations .............................................5 + 5. Security Considerations .........................................5 + 6. Acknowledgments .................................................5 + 7. Normative References ............................................5 + 8. Informative References ..........................................5 + + + + + + + +Metz, et al. Standards Track [Page 1] + +RFC 5003 AII Types for Aggregation September 2007 + + +1. Introduction + + [RFC4447] defines the signaling mechanisms for establishing point- + to-point pseudowires (PWs) between two provider edge (PE) nodes. + When a PW is set up, the LDP signaling messages include a forwarding + equivalence class (FEC) element containing information about the PW + type and an endpoint identifier used in the selection of the PW + forwarder that binds the PW to the attachment circuit at each end. + + There are two types of FEC elements defined for this purpose: PWid + FEC (type 128) and the Generalized ID (GID) FEC (type 129). The PWid + FEC element includes a fixed-length 32-bit value called the PWid that + serves as an endpoint identifier. The same PWid value must be + configured on the local and remote PE prior to PW setup. + + The GID FEC element includes TLV fields for attachment individual + identifiers (AIIs) that, in conjunction with an attachment group + identifier (AGI), serve as PW endpoint identifiers. The endpoint + identifier on the local PE (denoted as ) is + called the source attachment identifier (SAI) and the endpoint + identifier on the remote PE (denoted as ) + is called the target attachment identifier (TAI). The SAI and TAI + can be distinct values. This is useful for applications and + provisioning models where the local PE (with a particular SAI) does + not know and must somehow learn (e.g., via Multiprotocol BGP (MP-BGP) + auto-discovery) of remote TAI values prior to launching PW setup + messages towards the remote PE. + + The use of the GID FEC TLV provides the flexibility to structure + (source or target) AII values to best fit the needs of a particular + application or provisioning model [L2VPN-SIG]. For example, an AII + structure that enables many individual AII values to be identified as + a single value could significantly reduce the burden on AII + distribution mechanisms (e.g., MP-BGP) and on PE memory needed to + store this AII information. It should be noted that Pseudowire + Emulation Edge-to-Edge (PWE3) signaling messages will always include + a fully qualified AII value. + + An AII that is globally unique would facilitate PW management and + security in large inter-AS (autonomous system) and inter-provider + environments. Providers would not have to worry about AII value + overlap during provisioning or the need for AII network address + translation (NAT) boxes during signaling. Globally unique AII values + could aid in troubleshooting and could be subjected to source- + validity checks during AII distribution and signaling. An AII + automatically derived from a provider's existing IP address space can + simplify the provisioning process. + + + + +Metz, et al. Standards Track [Page 2] + +RFC 5003 AII Types for Aggregation September 2007 + + + This document defines an AII structure based on [RFC4447] that: + + o Enables many discrete attachment individual identifiers to be + summarized into a single AII summary value. This will enhance + scalability by reducing the burden on AII distribution mechanisms + and on PE memory. + + o Ensures global uniqueness if desired by the provider. This will + facilitate Internet-wide PW connectivity and provide a means for + providers to perform source validation on the AII distribution + (e.g., MP-BGP) and signaling (e.g., LDP) channels. + + This is accomplished by defining new AII types and the associated + formats of the value field. + +2. Specification of Requirements + + 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 [RFC2119]. + +3. Structure for the New AII Type + + [RFC4447] defines the format of the GID FEC TLV and the use and + semantics of the attachment group identifier (AGI). + +3.1. AII Type 1 + + AII Type 1 has been allocated by IANA for use with provisioning + models requiring a fixed-length 32-bit value [L2VPN-SIG]. This value + is unique on the local PE. + +3.2. AII Type 2 + + The AII Type 2 structure permits varying levels of AII summarization + to take place, thus reducing the scaling burden on the aforementioned + AII distribution mechanisms and PE memory. In other words, it no + longer becomes necessary to distribute or configure all individual + AII values (which could number in the tens of thousands or more) on + local PEs prior to establishing PWs to remote PEs. The details of + how and where the aggregation of AII values is performed and then + distributed as AII reachability information are not discussed in this + document. + + AII Type 2 uses a combination of a provider's globally unique + identifier (Global ID), a 32-bit prefix field, and a 4-octet + attachment circuit identifier (AC ID) field to create globally unique + AII values. + + + +Metz, et al. Standards Track [Page 3] + +RFC 5003 AII Types for Aggregation September 2007 + + + The encoding of AII Type 2 is shown in Figure 1. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AII Type=02 | Length | Global ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Global ID (contd.) | Prefix | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Prefix (contd.) | AC ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AC ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1. AII Type 2 TLV Structure + + o AII Type = 0x02 + + o Length = length of value field in octets. The length is set to + 12. + + o Global ID = This is a 4-octet field containing a value that is + unique to the provider. The global ID can contain the 2-octet or + 4-octet value of the provider's Autonomous System Number (ASN). + It is expected that the global ID will be derived from the + globally unique ASN of the autonomous system hosting the PEs + containing the actual AIIs. The presence of a global ID based on + the provider's ASN ensures that the AII will be globally unique. + + If the global ID is derived from a 2-octet AS number, then the + two high-order octets of this 4-octet field MUST be set to zero. + + Please note that the use of the provider's ASN as a global ID + DOES NOT have anything at all to do with the use of the ASN in + protocols such as BGP. + + o Prefix = The 32-bit prefix is a value assigned by the provider or + it can be automatically derived from the PE's /32 IPv4 loopback + address. Note that, for IP reachability, it is not required that + the 32-bit prefix have any association with the IPv4 address + space used in the provider's IGP or BGP. + + o Attachment Circuit (AC) ID = This is a fixed-length 4-octet field + used to further refine identification of an attachment circuit on + the PE. The inclusion of the AC ID is used to identify + individual attachment circuits that share a common prefix. + + + + + +Metz, et al. Standards Track [Page 4] + +RFC 5003 AII Types for Aggregation September 2007 + + +4. IANA Considerations + + IANA has allocated a value from the "Attachment Individual Identifier + (AII) Type" registry defined in [RFC4446]. + + The value for this AII type is 0x02. + +5. Security Considerations + + AII values appear in AII distribution protocols [L2VPN-SIG] and PW + signaling protocols [RFC4447] and are subject to various + authentication schemes (i.e., MD5) if so desired. + + The use of global ID values (e.g., ASN) in the inter-provider case + could enable a form of source-validation checking to ensure that the + AII value (aggregated or explicit) originated from a legitimate + source. + +6. Acknowledgments + + Thanks to Carlos Pignataro, Scott Brim, Skip Booth, George Swallow, + and Bruce Davie for their input into this document. + +7. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and + G. Heron, "Pseudowire Setup and Maintenance Using the + Label Distribution Protocol (LDP)", RFC 4447, April 2006. + + [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to + Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. + +8. Informative References + + [L2VPN-SIG] Rosen, E., Luo, W., Davie, B., and V. Radoaca, + "Provisioning, Autodiscovery, and Signaling in L2VPNs", + Work in Progress, May 2006. + + + + + + + + + + + +Metz, et al. Standards Track [Page 5] + +RFC 5003 AII Types for Aggregation September 2007 + + +Authors' Addresses + + Luca Martini + Cisco Systems, Inc. + 9155 East Nichols Avenue, Suite 400 + Englewood, CO, 80112 + EMail: lmartini@cisco.com + + Chris Metz + Cisco Systems, Inc. + 3700 Cisco Way + San Jose, Ca. 95134 + EMail: chmetz@cisco.com + + Florin Balus + Alcatel-Lucent + 701 East Middlefield Rd. + Mountain View, CA 94043 + EMail: florin.balus@alcatel-lucent.com + + Jeff Sugimoto + Nortel Networks + 3500 Carling Ave. + Ottawa, Ontario, CANADA + EMail: sugimoto@nortel.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Metz, et al. Standards Track [Page 6] + +RFC 5003 AII Types for Aggregation September 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, 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, THE IETF TRUST 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 BCP 78 and BCP 79. + + 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 + http://www.ietf.org/ipr. + + 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. + + + + + + + + + + + + +Metz, et al. Standards Track [Page 7] + -- cgit v1.2.3