Attachment Individual Identifier (AII) Types for Aggregation
RFC 5003
|
| Document |
Type |
|
RFC - Proposed Standard
(September 2007; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5003 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Mark Townsley
|
|
Send notices to |
|
(None)
|
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
Show full document text