Attachment Individual Identifier (AII) Types for Aggregation
RFC 5003

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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