1 files changed, 395 insertions, 0 deletions
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 <AGI, source AII, or SAII>) is
+   called the source attachment identifier (SAI) and the endpoint
+   identifier on the remote PE (denoted as <AGI, target AII, or TAII>)
+   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]
+