Internet DRAFT - draft-bergman-vpls-igp-auto-discovery
draft-bergman-vpls-igp-auto-discovery
Provider Provisioned VPN Working Group Oded Bergman
Internet Draft Eran Mann
Expiration Date: January 2005 MRV
Scott Kotrla
MCI
July 2004
VPLS Node Auto Auto-Discovery Using IGP
draft-bergman-vpls-igp-auto-discovery-00.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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
2. Table of Contents
1. Status of this Memo...........................................1
2. Table of Contents.............................................1
3. Specification of Requirements.................................2
4. Abstract......................................................2
5. Overview......................................................2
6. VPLS discovery procedure......................................3
6.1. VPLS auto discovery procedural overview.....................3
6.2. Node Discovery Using IGP protocol...........................3
6.2.1. OSPF VPLS PE Node Opaque LSA Format.......................3
6.2.2. LSA type..................................................3
6.2.3. LSA ID....................................................3
6.2.4. LSA Header................................................4
6.2.5. TLV Header................................................4
6.3. Node Auto discovery procedure...............................7
7. VPN and VC Auto discovery.....................................8
7.1. LDP signaling for VPN service and VC discovery..............8
7.1.1. VPN Auto Discovery........................................8
7.1.2. VC Label Signaling........................................8
7.2 VPN service and VC discovery using IGP additional LSA TLV ...8
8. Intellectual Property.........................................9
9. Full Copyright Statement......................................9
10. References...................................................9
11. Authors' Addresses..........................................10
O.Bergman, et al. [Page 1]
Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004
3. 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 RFC 2119
4. Abstract
This Internet Draft describes a method for automatic discovery of
Virtual Private LAN Service (VPLS) PE nodes and services, in order
to establish VPLS networks.
The node discovery is done using new Interior Gateway Protocol (IGP)
link-state advertisements (LSA), and service discovery is done by using
targeted-LDP address messages as was suggested by previous drafts.
In previous drafts VPLS PE nodes discovery was made via unsolicited LDP
and required establishment of hop by hop LDP sessions across the
network. This memo suggests the removal of the need for hop by hop
unsolicited LDP advertisements in order to discover the VPLS PE nodes.
It enables carriers to use any desired protocol to signal the MPLS LSP
tunnels underlying the VPLS(VPLS (for example [RSVP-TE] Or [LDP]).
This memo also describes a method that enables carriers to establish a
partial VPLS mesh according to a new VPLS group advertisement in the
IGP LSA.
The goal is to create VPLS networks with a minimum amount of
configuration, while maintaining (and improving when
possible) network scalability.
5. Overview
As L2 VPN services are being deployed in carriers' networks to serve
the growing demand for multipoint L2 VPNs, more Virtual Private LAN
Services (VPLS) networks are being established to provide these
services.
The creation and configuration of these VPLS networks has still not
been standardized, although several Auto discovery approaches have been
suggested. Some require an external RADIUS server as [RADIUS]
describes, and some use an expensive provisioning system. Others execute
the Auto discovery by using unsolicited LDP signaling as described in
[VPLS DISCOVER] and [VHLS DISCOVER] drafts. This document describes a
method for VPLS PE node Auto discovery using IGP protocols (such as
OSPF and ISIS) link-state advertisements (LSA) mechanism, and service
discovery using targeted-LDP.
The new IGP LSA includes information on the PE router service
capabilities. Optional additional information enables VPLS services to
be part of 32 service groups in order to reduce the number of MPLS
tunnels and targeted LDP sessions.
Based on the IGP LSA information, targeted-LDP sessions are set for
service discovery and MPLS tunnels are built between all the VPLS PE
routers within the same group.
This method enable carriers to use any desired MPLS signaling protocol
as RSVP-TE or LDP, according to the carrier requirements.
O.Bergman, et al. [Page 2]
Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004
The service discovery can be done in several ways, this draft propose
to use [VHLS DISCOVER] Service discovery. In [VHLS DISCOVER], address
messages in targeted LDP sessions are used to advertise the VPLS
services.
Other VPLS service discovery methods can also use the VPLS nodes
discovery that is described in this memo.
6. VPLS discovery procedure
6.1. VPLS auto discovery procedure overview
- Discover the VPLS PE routers using OSPF [OPAQUE LSA] and create
the VPLS capable PE routers list.
- Build MPLS LSP tunnels to all the PE routers in the list,according
according to the advertised VPLS protocol capabilities.
- Use the list to create targeted-LDP sessions for VPLS services
discovery.
- Use the VPLS services discovery to build VC PWE connections to
each supported service.
6.2. Node Discovery Using IGP protocol
Since MPLS is using an IGP protocol to create the network topology and
find all the PE routers, it can also be used to find which PE router
supports VPLS and what capabilities are available in each router. This
memo explains in more details how OSPF [OPAQUE LSA] option can be used
for this purpose. The same principle can be applied when using ISIS,
and it will be described in a future release of this memo.
6.2.1. OSPF VPLS PE Node Opaque LSA Format
Using OSPF Opaque LSA to discover VPLS PE routers can be done by defining
a new type of LSA or using an existing LSA with an additional
Type/Length/Value (TLV) type, both options are valid. This Memo suggest the
use of a new Opaque LSA type, however the existing Traffic Engineering (TE)
Opaque LSA defined in [OSPF-TE] or the Router Information Opaque LSA
defined in [OSPF-CAP], can be also used with an additional TLV type for
VPLS PE router.
6.2.2. LSA type
This extension makes use of the OSPF Opaque LSA.
Three types of Opaque LSAs exist, each of which has a different flooding
scope. This proposal uses only Type 10 LSAs, which have an area flooding
scope.
A new LSA type needs to be defined (subject to IANA approval), VPLS PE
node LSA. This LSA describes VPLS PE routers and advertises their
capabilities.
6.2.3. LSA ID
The LSA ID of an Opaque LSA is defined as having eight bits of type data
and 24 bits of type-specific data. The VPLS PE node LSA will use a previously
un-used type, which could currently be 5 (subject to IANA approval).
The remaining 24 bits are the Instance field, as follows:
O.Bergman, et al. [Page 3]
Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Instance field is an arbitrary value used to maintain multiple VPLS PE
node LSAs. A maximum of 16777216 VPLS PE node LSAs may be sourced by a
single system. The LSA ID has no topological significance.
6.2.4. LSA Header
The VPLS PE node LSA starts with the standard LSA header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.2.5. TLV Header
A new type of top level TLV is needed to support VPLS advertisement.
1 - VPLS service capabilies (new)
A VPLS PE router advertises the following TLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPLS Router-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type | Service Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Signaling capabilities | Control Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPLS Group bitmap mask (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Service Parameters (variable length) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
O.Bergman, et al. [Page 4]
Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004
- VPLS Router-id:
VPLS Router-id field. This is a 32 bit VPLS router-id, which will be used
by the MPLS signaling protocols as router-id.
- Service Type:
Service Type field. This has the following values:
Value Node Type
-----------------
0 Undefined
1 VPLS core node
2 VHLS PE (proposed)
A node may support multiple service types, in which case it will advertise
multiple Service Capabilities TLVs.
- Service Instance:
Service Instance field. This field contains a 16-bit index used as an
instance identifier for the service. This enables, for
example, one Service Provider to create multiple sets of VPLS nodes
providing different grades of service. Note that a node may have
multiple service instances, in which case it will advertise multiple
Service Capabilities TLVs. Note also that in the case of VPLS, one
service instance may contain multiple VPLS services.
This field must have a value of 0 when advertising a VHLS capable
PE node.
- LSP Signaling Capabilities:
LSP Signaling Capabilities field. Each VPLS capable PE router specifies
which tunnel signaling protocol it can use for negotiating and exchanging
of labels. This is a 16 bit bitmap field.
This has the following values:
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C|S|R|D|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit Node Type
-----------------
15 (U) Unsolicited LDP
14 (D) Downstream on demand LDP
13 (R) RSVP-TE
12 (S) LDP Proxy server
11 (C) LDP Proxy client
0-10 Reserved
O.Bergman, et al. [Page 5]
Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004
Bit 15: Unsolicited LDP. The router indicates that it is capable of
signaling LSP tunnels using unsolicited LDP.
Bit 14: Down stream on demand LDP. The router indicate that it is capable
of signaling LSP tunnels using LDP downstream on demand.
Bit 13: RSVP-TE. The router indicate that it is capable of signaling LSP
tunnels using RSVP-TE.
Bit 12: LDP Proxy server. The router indicate that it functions as an LDP
Proxy server [LDP PROXY] for all the VPLS groups which are set in
the VPLS Group bitmap mask field.
Bit 11: LDP Proxy client. The router indicate that it negotiates VPLS
Thought LDP Proxy server to the all the VPLS groups which are set
in the VPLS Group bitmap mask field.
Bit 0-10: Reserved.
- Control Flags
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bit 0-14 (reserved) : Reserved for future use- must be set to zero on
transmit and ignored on receive.
Bit 15 (G): VPLS Group bitmap mask option, this bit must be set if
VPLS Group bitmap mask is present and unset otherwise.
- VPLS Group bitmap mask:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VPLS Group bitmap mask. This field is a 32 bits bitmap mask of VPLS
groups. Each bit of the 32 indicates wether or not a VPLS service
belonging to the corresponding group is configured on the advertising
router.
This bitmap optimizes the VPLS service discovery and connections mesh.
Each VPLS router will negotiate the VPLS services only with other routers
that have the same bit set in the VPLS Group bitmap.
This field in combination with other capabilities fields can be used for
discovery of other common services such as LDP Proxy server or client.
O.Bergman, et al. [Page 6]
Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004
- Service Parameters:
Optional Service Parameters. Some service types may have
additional parameters that must be discovered for correct operation
of the service. This field is not required for VPLS. Note that for a
given service type and instance a node will only advertise one
Service Capabilities TLV, with one set of Service Parameters.
6.3. Node Auto discovery procedure
Each VPLS capable PE router MUST advertise a VPLS PE node [OPAQUE LSA]
with exactly one VPLS router-id TLV for each pair of <service-type,
service-instance> configured on it.
The advertising router MAY include the VPLS Group bitmap mask in the VPLS
router-id TLV, in which case it MUST set the G bit in the Control Flags.
Upon every configuration change, which changes the data in any of the VPLS
PE node LSAs advertised by a PE router, the router MUST regenerate the LSA
with the new data.
Whenever a <service-type, service-instance> pair ceases to be configured
on the router, the router MUST withdraw the corresponding VPLS PE node
LSA.
Upon receiving the VPLS information from another VPLS PE router, a
verification and initialization process begins.
The Control Flags field of the VPLS router-id TLV is checked.
If the (G) bit is set then the VPLS Group bitmap mask bit is in use, the
receiving router tests if the sending router belongs to any VPLS Group to
which the receiving router belongs.
If the (G) flag bit is not set then the receiving router considers the
sending router to be part of all the VPLS groups.
If there is at least one group to which both routers belong, then the
receiving PE router adds the sending router-id to a list of VPLS
routers. Adding a router-id to a list of VPLS routers triggers the
following:
- The receiving PE router initiates the signaling of a MPLS LSP to the
senderÆs router-id (if one doesnÆt already exist).
- A VPLS service discovery procedure is initiated.
According to the advertised MPLS protocol capabilities in the
LSP Signaling protocol field of the TLV the receiving router
initiates an MPLS tunnel LSP in the following order:
If the RSVP-TE bit is set the PE routers will prefer it to the other LDP
options and use RSVP-TE to setup the MPLS LSP tunnel.
If the RSVP-TE bit is not set then the preferred option is
LDP downstream on demand. In case this bit is set to zero then
unsolicited LDP is used.
O.Bergman, et al. [Page 7]
Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004
Note:
It is the carrier's responsibility to make sure that all of the
MPLS signaling protocols will have a viable path.
The other process that the receiving router starts is the VPLS service
discovery. If service discovery is performed according to [VHLS-DISCOVERY]
the receiving router initiates a Targeted-LDP session to the sending
router-id for this purpose. The VPLS service discovery procedure is
described in paragraph (7.).
Whenever a VPLS PE node LSA is readvertised or withdrawn, the receiving
router initiates removal of all the services and the MPLS tunnels to the
sender which are no longer necessary, and removes the sender form the VPLS
routers list if they do not share a common service group anymore.
7. VPN and VC Auto discovery
7.1. LDP signaling for VPN service and VC discovery
This part is described in detail in [VHLS DISCOVER]
7.1.1. VPN Auto Discovery
The VPN service discovery uses targeted LDP peers to all the known VPLS
PE routers that are within the same group (as discovered by IGP). A new
address message TLV is used to advertise the VPLS services. This mechanism
is described in [VHLS DISCOVER] paragraph 6.2
7.1.2. VC Label Signaling
The VC Label Signaling uses targeted LDP peers and the information
collected by the VPN service discovery. This mechanism is described in
[VHLS DISCOVER] paragraph 6.3
7.2 VPN service and VC discovery using IGP additional LSA TLV
An alternative way to perform the services auto discovery is to
create another TLV type for IGP LSA that will be advertised by each PE
router in a separate LSA that includes all the VPN services. In this
case the only protocol that will be used for VPLS discovery will be the
IGP which will dramatically reduce the number of targeted-LDP sessions.
This method is especially useful for PE routers which participate only
in a small number of services.
This option may be defined in future versions of this Memo.
8. Intellectual Property
MRV is filing Intellectual Property rights for the technology in this
document.
O.Bergman, et al. [Page 8]
Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004
9. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
10. References
[LDP] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A.
Fredette, B. Thomas. January 2001. RFC 3036.
[RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209, December 2001.
[RSVP] Braden et al, "Resource ReSerVation Protocol (RSVP) - Version
1 Functional Specification", RFC 2205, September 1997.
[OSPF-TE] Katz, D., D. Yeung and K. Kompella, "Traffic Engineering
Extensions to OSPF", RFC 3630, September 2003.
[OPAQUE LSA] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
1998.
[VPLS] M. Lassere, V. Kompella, (eds.), "Virtual Private LAN Services
over MPLSö, Work in progress, draft-ietf-ppvpn-vpls-ldp-03.txt,
April 2004.
[RADIUS] J. Heinanen, G. Weber, ôUsing RADIUS for PE-Based VPN
Discoveryö, Work in progress,
draft-ietf-l2vpn-radius-pe-discovery-00.txt, February 2004.
[VPLS DISCOVER] O. Stokes et al, ôDiscovering Nodes and Services in a
VPLS Networkö, Work in progress,
draft-stokes-ppvpn-vpls-discover-00.txt, June 2002.
O.Bergman, et al. [Page 9]
Internet Draft draft-bergman-vpls-igp-auto-discovery-00.txt July 2004
[VHLS DISCOVER] A. Sodder et. Al., ôVirtual Hierarchical LAN Servicesô,
Work in progress, draft-sodder-ppvpn-vhls02.txt,
April 2003.
[PWE3-CTL] L. Martini et al, Pseudowire Setup and Maintenance using
LDP, Work in progress,
draft-ietf-pwe3-control-protocol-05.txt, December 2003.
[OSPF-CAP] A. Lindem, ôExtensions to OSPF for Advertising Optional
Router Capabilitiesö, Work in progress,
draft-ietf-ospf-cap-03.txt, July 2004.
[LDP PROXY] V. Kompella, "An LDP Proxy for Non-Adjacent LDP Sessions"
draft-vkompella-mpls-ldp-proxy-00.txt, Work in progress
11.Author's Addresses
Oded Bergman
MRV
20415 Nordhoff Street
Chatsworth, CA USA 91311
Phone:+1-818-465-4450
Email:obergman@mrv.com
Eran Mann
MRV
20415 Nordhoff Street
Chatsworth, CA USA 91311
Phone: +818-773-0900,
+972-4-9936297
Email:emann@mrv.com
Scott Kotrla
MCI
400 International Pkwy
Richardson, TX 75081
Phone: +1-972-729-3407
Email:scott.kotrla@mci.com
O.Bergman, et al. [Page 10]
