Internet DRAFT - draft-stein-ldp-auto
draft-stein-ldp-auto
L2VPN Working Group Y(J). Stein
Internet-Draft RAD Data Communications
Expires: January 11, 2006 S. Delord
France Telecom
July 10, 2005
LDP-based Autodiscovery for L2 Services
draft-stein-ldp-auto-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 11, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Current L2VPN implementations that use LDP for label binding require
another protocol to dynamically detect which PEs belong to a given
VPN. We herein propose a simple extension to LDP consisting of a
message with which a PE announces its desire to join an existing VPN.
The technique is equally applicable to HVPLS, multisegment VPLS and
VPWS, and may be especially attractive for access networks employing
MPLS.
Stein & Delord Expires January 11, 2006 [Page 1]
Internet-Draft vpls-ldp-auto July 2005
1. Introduction
VPLS networks based on LDP signaling, as described in [VPLS-LDP],
transparently interconnect N physically separated LANs belonging to a
single customer. VPLS provides this multipoint to multipoint service
based on a full mesh of Ethernet PWs [ETHERNET-PW]. We shall call
each multipoint to multipoint network a VPLS instance or simply a
VPN.
In the following we assume a service provider network, consisting of
PE (provider edge) and P (provider) LSRs. The PEs must be VPLS-
capable, i.e. they must be able to perform all the functionality
described in [VPLS-LDP], including setting up of Ethernet PWs,
encapsulating and properly forwarding incoming Ethernet frames, and
802.1D learning. The PE LSRs are connected to CE (customer edge)
devices in the customer network, which may be Ethernet switches or IP
routers. The connection between PE and CE is called the attachment
circuit (AC).
Before offering VPLS services the service provider must provision a
full mesh MPLS tunnels connecting all PEs; this being accomplished by
manual configuration, BGP, RSVP-TE or LDP. Each VPLS instance
defines a subset of the PEs, namely those connected to CEs that
require the VPLS service. We shall call this subset of PEs the Vset.
The VPLS service is implemented by means of Ethernet PWs inside the
MPLS tunnels that we have assumed to connect every pair of PEs in the
Vset. These PWs may be set up manually, or by using the LDP
extensions defined in the PWE control protocol [PWE-CONTROL].
When a PE, not originally in the Vset wants to join the VPN, new
Ethernet PWs must be set up between it and all the PEs already in the
Vset. The act of joining a VPLS instance conceptually consists of
two parts, namely discovering the Vset, and thereafter setting up
(e.g. by using the PWE control protocol) PWs to all PEs in the Vset.
Assuming an efficient mechanism for Vset discovery, the entire VPLS
instance may be built iteratively by growing the Vset, starting with
a single PE being told that it is in the Vset for the new VPLS
instance.
Vset discovery may be explicit or implicit. With explicit Vset
discovery, PEn determines that PE1 through PE(n-1) are in the Vset,
and joins by setting up n-1 Ethernet PWs. With implicit Vset
discovery PEn announces to all VPLS-capable PEs that it wishes to
join the particular VPLS instance, and PEs already in the Vset
initiate the PW setup. We adopt here the implicit method as it
minimizes the amount of messaging traffic, and is conceptually more
compatible with MPLS downstream label distribution procedures.
Rather than trying to directly locate participating PEs (e.g. by
Stein & Delord Expires January 11, 2006 [Page 2]
Internet-Draft vpls-ldp-auto July 2005
requiring all PEs to periodically advertise the list of VPNs they
handle), it makes sense for the PE desiring to join the VPN to
advertise this fact to all the other PEs, permitting them to respond
when they belong to the VPN. This method minimizes overhead and
shortens the time it takes until all PEs know of the new VPN member.
The discovery of the Vset of an extant VPLS instance is not the only
autodiscovery problem involved in provisioning networks capable of
providing VPLS services. The VPLS-capable PEs must a priori know
each other in order to set up the initial set of MPLS tunnels, and
the PE must recognize CEs in order to set up the attachment circuits.
However, we contend that the Vset discovery problem is of a different
nature than the others. The number of PEs in a network is relatively
limited and static, and in most cases autodiscovery protocols already
exist for this problem. Provisioning of new attachment circuits is
also relatively rare, and will often require management intervention.
On the other hand the adding of a LAN to an existing VPN is expected
to be much more prevalent. Since a large number of PEs may be
involved in any particular VPN, manual configuration of the VPLS is
logistically difficult and error-prone. Scalability requires an
autodiscovery protocol for this task, and several such mechanisms
exist, for example in BGP [BGP-AUTO] and extensions to RADIUS
[RADIUS-AUTO].
The autodiscovery protocol described here is limited to the problem
of discovering the Vset. We always assume that attachment circuits
are in place, and that there is some method to inform the PE that a
given CE needs to join a given VPLS, and for the PE to authenticate
this request. For the simplest case we further assume that MPLS
tunnels capable of supporting Ethernet PWs have been preprovisioned
between every two PEs in the provider network, and that LDP sessions
are already running between every pair of PEs. For more complex
cases, e.g. HVPLS and multisegment VPLS, we assume that the
existence of MPLS tunnels and LDP sessions between the end PEs and
the stitching nodes.
As we deal solely with Vset discovery, the actual setting up of PWs
is beyond our scope. This setting up of Ethernet PWs trivially
follows for the simple case, but the PW placement problem may be
complex for other cases. For example, for HVPLS with MPLS-based
spoke PWs, the MTUs that aggregate Ethernet traffic from several
customers originate the request for Vset discovery, but as they are
directly aware of only one PE, the discovery messaging must be
forwarded by that PE to the others with which it is fully
interconnected.
Another case of interest is multisegment VPLS, which we define as a
VPN whose Vset consists of PEs in multiple independently managed
Stein & Delord Expires January 11, 2006 [Page 3]
Internet-Draft vpls-ldp-auto July 2005
domains, and thus requires multisegment PWs [MSPWs]. Here there will
be S-PEs that straddle the various domains, and our autodiscovery
mechanism will need to traverse these S-PEs as the PEs in distinct
domains are not linked by LDP sessions. Note that since our
mechanism is limited to Vset discovery, it is sufficient for our
purposes for a PE to know of a single S-PE enabling access to each
foreign domain, and this S-PE will not necessarily be that which is
eventually traversed by the PW.
The present document proposes a simple Vset autodiscovery mechanism
that requires only the extension of the LDP protocol that has been
assumed to already be running between the PEs. The method proposed
is distributed and does not require a central server holding VPLS
member information. Rather than querying all VPLS-capable PEs to
determine whether they belong to the Vset, each PE desiring to join a
VPLS instance announces this by a new JOIN TLV, and receiving PEs
that belong to the Vset respond by setting up the required PWs. In
Section 2 we discuss why this method is most suitable for access
networks; in Section 3 we motivate the use of human readable VPN
identifiers; in Section 4 we detail the required extensions to LDP;
Section 5 extends the discussion to more complex cases; and in
Section 6 we briefly cover the security considerations.
2. Access Networks
The autodiscovery method described herein may be particularly
suitable for access networks. Core networks will typically be
running BGP-4, and thus have at their disposal the autodiscovery
mechanisms described in [VPLS-BGP]. In addition the core network may
already be providing L3VPN services, and thus already utilizing BGP-
based autodiscovery mechanisms.
However, in the case of access networks, such a protocol will
frequently not be available to the service provider or not be
completely suitable, and this for at least two reasons.
First, the processing power of access network forwarding devices may
be quite limited as compared to backbone routers. This is due to the
fact that the total number of devices is significantly greater in the
access/metro segment than in the core network. Typically DSLAMs
represent several thousand devices, and so need to be as simple as
possible to keep the global network complexity (and cost) low.
Second, the topology of an access network may also be much simpler
than the topology of a backbone network. For example, it is quite
common to have a DSLAM with only a single physical attachment, (or
perhaps a dual physical attachment for redundancy) to the metro/
backbone area. Such DSLAMs may not even run an IGP and employ only
Stein & Delord Expires January 11, 2006 [Page 4]
Internet-Draft vpls-ldp-auto July 2005
static routes in order to avoid CPU overload.
Despite these constraints, advanced services, such as interconnecting
two endpoints located on the same or different access networks (e.g.
two DSLAMs that do not belong to the same geographical area) are
still required by the service provider. Solutions such as [MSPWs]
allow the total number of PWs to grow without impacting the control
plane, by limiting the number of targeted LDP sessions between the
U-PEs to only a few S-PEs. However such solutions at present still
require BGP or RADIUS for the auto-discovery process, in addition to
LDP for setting up of the PWs.
Our proposal extends LDP with new TLVs thus enabling auto-discovery
in the access network without requiring burdening down the access
network forwarding devices with additional protocols. The TLVs reuse
the endpoint identifiers defined in [PWE-CONTROL]. This same LDP-
based autodiscovery method may be used in the core network, but
alternatively the core network may employ [BGP-AUTO].
3. Importance of unique and meaningful VPN identifiers
According to [VPLS-LDP] each VPLS instance must be assigned a
globally unique identifier, a VPNID. This identifier is often
numeric, for example, a 7-byte VPN Identifier per RFC 2685 [VPN-ID].
A useful format for the VPN identifier used for the purpose of
autodiscovery is a human readable name in URL-like format. This
suggestion has been made in this context before, and is realized in
the VPN identifier record used in RADIUS discovery [RADIUS]. Such an
identifier minimizes the chance of accidental overlap with other
VPNIDs, and eliminates the need for maintaining a network-wide
directory of VPNIDs.
On the other hand, for the purpose of setting up the Ethernet PWs
comprising the VPLS, an AGI is required. According to [PWE-CONTROL],
the AGI may be of arbitrary format, and
"The details of how to construct the AGI and AII fields
identifying the pseudowire endpoints are outside the scope of this
specification. Different pseudowire application, and different
provisioning models, will require different sorts of AGI and AII
fields. The specification of each such application and/or model
must include the rules for constructing the AGI and AII fields."
When possible the AGI should be simply be the URL-like VPNID herein
described. When this is not possible, for example, when a RFC 2685
VPN-ID is needed, a mechanism must be provided to translate the URL
to the requisite format.
Stein & Delord Expires January 11, 2006 [Page 5]
Internet-Draft vpls-ldp-auto July 2005
4. LDP extensions
In the standard model, a full mesh of LDP sessions is already running
between all PEs that may wish to join the VPN. In the multisegment
case, we assume LDP sessions between the U-PE and related S-PEs. It
is over these LDP sessions regulating the MPLS transport tunnels that
the new TLVs are advertised.
When a PE needs to add a CE to a VPN, it first consults a table to
determine whether it is already participating in this VPLS instance
for some other CE. If it does, then all that needs to be done is to
connect the new CE to the existing bridge function and Ethernet PWs.
If it does not, the joining PE must first allocate a bridge function
to perform the 802.1 functionality and to add the VPNID to the table
of VPNs in which it participates. Next, it sends an LDP message
containing a VPN JOIN TLV to all the PEs with which it maintains LDP
sessions. This TLV has the following format.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| JOIN Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AGI Type | Length | AGI Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AGI Value (contd.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional VPN Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
U (1 bit) The unknown bit MUST be cleared. If the VPN join format
is not understood, the sending PE must be informed that its
attempt to join has been ignored. In this case an alternative
mechanism must be employed to determine whether the remote PE
participates in the VPN.
F (1 bit) The forwarding bit is not used, and MUST be cleared.
Type (14 bits) This field MUST be set to whatever value is assigned
by IANA for this purpose.
Length (16 bits) This field specifies the total length of the VPLS
identifier in bytes.
AGI TLV Attachment Group Identifier TLV per [PWE-CONTROL].
Optional VPN Parameters These optional TLVs may have to be specified
for proper or optimal operation of the service.
When a PE needs to join a VPLS instance, it sends the JOIN TLV to all
VPLS-capable PEs to which it is connected. The JOIN TLV is similar
Stein & Delord Expires January 11, 2006 [Page 6]
Internet-Draft vpls-ldp-auto July 2005
to a label REQUEST, but the corresponding label mapping is contingent
on the receiving PE belonging to the VPLS. However, the JOIN TLV
does not specify a FEC, rather it specifies a VPNID.
When a PE receives a JOIN message it checks the VPNIDs of all the
VPLS instances to which it belongs. If it finds a match it adds the
joining PE to the VPN-PE table, allocates a PW label, and distributes
this label to the sending PE via the LDP-based PW signaling protocol.
The label distribution message used MUST be of the Generalized PW ID
FEC Element (FEC type 129), with AGI set equal to the VPNID specified
in the JOIN message, and SAII and TAII set to zero. AIIs are not
needed for VPLS since packets received at the PE with the label
mapped to the VPLS instance, since the Ethernet frame is sent to a
bridging function that decides to which CE the frame needs to be
forwarded.
Once the PE that had sent the JOIN message receives the mapping
message with an AGI matching the VPNID, it adds the remote PE to its
VPN-PE table, allocates and sends back a PW label using the
Generalized PW ID FEC Element. This process is repeated for all PEs
in the VPN.
When a PE needs to leave a VPLS instance, it sends the LEAVE TLV to
all PEs to which it is connected that participate in the given VPN.
The format of the TLV is identical to the JOIN format, except for the
TYPE value, and not having any optional parameters. LEAVE messages
are similar to label RELEASE, but specifies a VPNID instead of a FEC.
When a PE receives a LEAVE message it checks the VPNIDs of all the
VPLS instances to which it belongs. If it finds a match, it frees
the corresponding PW label and sends a label WITHDRAWAL message.
5. Other Cases
The previous section dealt with signaling required for autodiscovery
and setting up of PWs for the simple VPLS case. In this section we
will extend this treatment to other cases, namely HVPLS [VPLS-LDP],
multisegment VPLS based on multisegment PWs [MSPWs], and VPWS.
In the HVPLS case the MTU originates the JOIN and LEAVE messages, but
it can send these only to the PE to which it is connected. The PE,
upon receiving a JOIN request, performs any authentication that is
required, and then notes the MTU's VPN participation in a VPN-MTU
table. It then forwards the JOIN request to all the PEs with which
it maintains LDP sessions. A PE receiving such a request checks its
VPN-MTU tables for membership, and if finding that its participation
is required adds the originating PE to its VPN-PE table, and send a
label mapping message back. Note that it does not need to inform
Stein & Delord Expires January 11, 2006 [Page 7]
Internet-Draft vpls-ldp-auto July 2005
attached MTUs of the new association, as this will be automatically
learned by the bridging function. If BGP is running between the PEs,
then [BGP-AUTO] could also be used.
When the originating PE receives a label mapping with AGI indicating
that it is in response to the previously sent JOIN, it adds the
remote PE to its VPN-PE table, and returns a label mapping message
with the same AGI to set up the other direction.
For the multisegment case the S-PE is required to forward JOIN
messages between the two segments (in both directions). The
assumption here is that LDP sessions are already running between the
U-PEs and their related S-PEs. Although there may be many S-PEs
between a pair of domains, it is sufficient for a single S-PE to be
designated as the point of contact between each pair of domains for
the purpose of autodiscovery. When a PE in one domain wants to join
a VPLS that extends over multiple domains, it sends JOIN messages
with a globally unique VPNID to all VPLS-capable PEs in its domain,
and to all S-PEs. The S-PEs forward the JOIN messages in their
respective domains. A receiving PE in the same domain as the
originating PE sends its label mapping back to the originating PE. A
PE in a different domain sends its label mapping to an S-PE, using
whatever mechanism is selected by the PWE3 WG for multisegment PW
setup. If BGP is running between the PEs, then [BGP-AUTO] could also
be used.
Although the scalability problem is less for VPWS, it may be
necessary to use the mechanism described herein in order to set up a
large number of point to point PWs. We shall deal solely with the
single segment case, although a similar method is applicable VPWS
based on MS-PWs.
When the PW can be uniquely identified by a 32-bit identifier, it is
sufficient to use the PWid FEC Element; the problem arises when we
wish to use a meaningful VPNID. In this case either side can send a
JOIN message containing the VPNID as AGI and an AII indication as an
optional parameter to all relevant PEs. The PE receiving the JOIN
which itself wishes to be part of that PW returns a generalized PW ID
label mapping with the VPNID as AGI, SAII as locally identified, and
TAII as received in the JOIN message.
6. Security Considerations
Security mechanisms are important for all automatic admission
mechanisms, and for VPNs the issues of security are paramount. The
responsibility for admission into a VPN rests with the service
provider, as this security is an integral part of the "private
service" being offered.
Stein & Delord Expires January 11, 2006 [Page 8]
Internet-Draft vpls-ldp-auto July 2005
In order to provide a pseudo-private service, the provider MUST check
the authorization of any request to join a VPN, and MUST ensure that
the packets are only delivered to the proper remote CE.
By using manual provisioning of the CE-PE portion of the VPN the
first component of the joining can be made relatively safe.
Mechanization of the PE to PE connection component eliminates errors,
and thus mitigates security problems of the second type.
It is recommended that LDP authentication methods be utilized to
deter unauthorized parties joining a VPLS instance.
7. IANA Considerations
In order to implement the LDP extensions defined here, we will need
two new LDP types, one for the VPN JOIN and one for the VPN LEAVE
TLV.
8. References
8.1 Normative References
[ETHERNET-PW] "Encapsulation Methods for Transport of Ethernet Frames
Over IP/MPLS Networks", September 2004,
draft-ietf-pwe3-ethernet-encap-08.txt (Work In Progress)
[LDP] Andersson, et al., "LDP Specification", RFC 3036
[MPLS] RFC 3032 "MPLS Label Stack Encoding"
[PWE-CONTROL] "Pseudowire Setup and Maintenance using LDP", March
2005, draft-ietf-pwe3-control-protocol-16.txt (Work In Progress)
[VPLS-LDP] "Virtual Private LAN Services over MPLS", Month 200x,
draft-ietf-l2vpn-vpls-ldp-0n.txt (Work In Progress)
[VPNID] RFC 2685 "Virtual Private Networks Identifier", September
1999
8.2 Informative References
[BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for Network-
based VPNs", draft-ietf-l3vpn-bgpvpn-auto-05.txt (Work In
Progress)
[MSPWs] "Pseudo Wire Switching",
draft-martini-pwe3-pw-switching-03.txt (Work In Progress)
[RADIUS-AUTO] "Radius/L2TP Based VPLS",
draft-ietf-l2vpn-l2tp-radius-00.txt (Work In Progress)
[VPLS-BGP] "Virtual Private LAN Service", Month 200x,
draft-ietf-l2vpn-vpls-bgp-0n.txt (Work In Progress)
9. Acknowledgments
The authors would like to thank Yuri Gittik and Philippe Niger for
interesting discussions and valuable contributions to the work herein
Stein & Delord Expires January 11, 2006 [Page 9]
Internet-Draft vpls-ldp-auto July 2005
presented.
Authors' Addresses
Yaakov (J) Stein
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719
ISRAEL
Phone: +972 3 645-5389
Email: yaakov_s@rad.com
Simon Delord
France Telecom
2 av. Pierre Marzin
Lannion 22300
FRANCE
Email: simon.delord@francetelecom.com
Stein & Delord Expires January 11, 2006 [Page 10]
Internet-Draft vpls-ldp-auto July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Stein & Delord Expires January 11, 2006 [Page 11]
