Internet Draft Igor Bryskin (Movaz Networks)
Category: Standards Track Lou Berger (LabN Consulting, LLC)
Expiration Date: August 2006
February 2006
OSPF Based L1VPN Auto-Discovery
draft-bryskin-l1vpn-ospf-auto-discovery-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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document defines an OSPF based layer-1 VPN auto-discovery
mechanism. This mechanism enables PEs using the OSPF IGP to
dynamically learn about existence of each other, and attributes of
currently configured CE-PE links and their associations with L1VPNs.
This document builds on [L1VPN-FRMWK] and provides an auto-discovery
mechanism as discussed in [L1VPN-BM].
Bryskin, Berger [Page 1]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
Contents
1 Terminology ............................................... 3
2 Introduction .............................................. 4
3 L1VPN Opaque LSA and its TLVs ............................. 5
3.1 L1VPN Opaque LSA .......................................... 6
3.2 L1VPN INFO TLV ............................................ 7
3.3 L1VPN PE Address TLV ...................................... 8
4 L1VPN Info TLV Processing ................................. 8
4.1 Discussion and Example .................................... 9
5 L1VPN PE Address TLV Processing ........................... 10
5.1 Example ................................................... 11
6 Backward compatibility .................................... 12
7 Security Considerations ................................... 12
8 Intellectual Property Statement ........................... 12
9 Acknowledgement ........................................... 13
10 References ................................................ 13
10.1 Normative References ...................................... 13
10.2 Informative References .................................... 14
11 Authors' Addresses ........................................ 14
12 Auto-Discovery Information ................................ 14
13 Full Copyright Statement .................................. 16
14 Intellectual Property ..................................... 17
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
Conventions used in this document
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].
1. Terminology
The reader of this document should be familiar with the terms used in
[L1VPN-FRMWK] and [L1VPN-BM]. In particular the following terms:
L1VPN - Layer One Virtual Private Network
CE - Customer (edge) network element directly connected to the
Provider network (terminates one or more links to one or
more PEs); it is also connected to one or more Cs and/or
other CEs
C - Customer network element that is not connected to the
Provider network but is connected to one or more other Cs
and/or CEs
PE - Provider (edge) network element directly connected to one or
more Customer networks (terminates one or more links to one
or more CEs associated with the same or different L1VPNs);
it is also connected to one or more Ps and/or other PEs
P - Provider (core) network element that is not directly
connected to any of Customer networks; P is connected to one
or more other Ps and/or PEs
LSDB - Link State Database: a data structure supported by an IGP
speaker
PIT - Port Information Table
CPI - Customer Port Identifier
PPI - Provider Port Identifier
Bryskin, Berger [Page 3]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
2. Introduction
The framework for Layer 1 VPNs is described in [L1VPN-FRMWK]. Basic
mode operation is further defined in [L1VPN-BM]. [L1VPN-BM] document
identifies the information that is necessary to map customer
information (ports identifiers) to provider information
(identifiers). It also states that this mapping information may be
provided via provisioning or via an auto-discovery mechanism. This
document provides such an auto-discovery mechanism using the OSPF
IGP. Figure 1 shows the L1VPN basic service being supported using
OSPF based L1VPN auto-discovery. See [L1VPN-BGP] for a parallel
L1VPN auto-discovery that uses BGP. The IGP approach described in
this document is particularly useful in networks where BGP is not
typically used.
PE PE
+---------+ +--------------+
+--------+ | +------+| | +----------+ | +--------+
| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
| CE1 |--| |PIT || OSPF LSAs | | PIT | |-| CE2 |
+--------+ | | ||<----------->| | | | +--------+
| +------+| Distribution| +----------+ |
| | | |
+--------+ | +------+| | +----------+ | +--------+
| VPN-B | | |VPN-B || -------- | | VPN-B | | | VPN-B |
| CE1 |--| |PIT ||-( GMPLS )--| | PIT | |-| CE2 |
+--------+ | | || (Backbone ) | | | | +--------+
| +------+| --------- | +----------+ |
| | | |
+--------+ | +-----+ | | +----------+ | +--------+
| VPN-C | | |VPN-C| | | | VPN-C | | | VPN-C |
| CE1 |--| |PIT | | | | PIT | |-| CE2 |
+--------+ | | | | | | | | +--------+
| +-----+ | | +----------+ |
+---------+ +--------------+
Figure 1: OSPF Auto-Discovery for L1VPNs
The approach used in this document to provide OSPF based L1VPN auto-
discovery uses an Opaque LSA of a new Opaque Type (referred as a
L1VPN LSA).
There are two TLV types defined for use within a L1VPN LSA. The
first, which is referred to as L1VPN Info TLV, is used to propagate
<CPI, PPI> tuple and VPIN ID mappings. The second, which is referred
to as L1VPN PE Address TLV, is used for multi- area configurations to
support identification of reachable PEs. The L1VPN PE Address TLVs
provide information necessary to validate the installation of L1VPN
Bryskin, Berger [Page 4]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
information carried in the L1VPN Info TLVs in a multi-area
configuration, similar to how ASBR information (OSPF LSAs type 4) is
used to validate AS external information (OSPF LSAs type 5) in
[RFC2328].
The reason for such validation is that the opaque LSA distribution
throughout multiple areas cannot be considered reliable. Consider the
situation when a PE has originated L1VPN LSA containing L1VPN Info
TLVs (which are of AS scope) for each of the locally configured CE-PE
links, and shortly after that goes out of service. PEs located in the
same area as the LSA originating PE have a way of identifying such an
event and can immediately invalidate the LSAs and update their PITs
appropriately. PEs located in other areas, however, will not "feel"
(notice) the absence of the advertising PE and will use the stale
advertisements for a considerable (up to 60 min) period of time
before the LSAs times out and corresponding PIT entries are removed.
This may prove to be unacceptable for both L1VPN service providers
and their customers.
One solution would be to flood L1VPN LSA containing L1VPN Info TLVs
within a single area and have ABRs re-originate them into other
areas. This, however, would increase the size of ABRs, LSDBs and
their CPU utilization during the flooding and DB synchronization
processes, and make the flooding of the L1VPN LSAs overall more
complex.
Therefore, we propose a validation mechanism similar to one that is
used in OSPF for distribution of external routes [RFC2328]. The idea
is to combine the AS scope advertising of more dynamic PE-CE link
information with the area scope advertising of more static PE ID
information and have the latter validate the former.
3. L1VPN Opaque LSA and its TLVs
This section defines the L1VPN Opaque LSA and its TLVs.
Bryskin, Berger [Page 5]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
3.1. L1VPN Opaque LSA
The format of a L1VPN LSA is as follows:
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 | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1VPN TLV(s) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LS age
As defined in [RFC2328]
Options
As defined in [RFC2328].
LS Type
This filed MUST be set to 11 when the L1VPN LSA contains a
L1VPN Info TLV, and 10 when the L1VPN LSA contains one or more
L1VPN PE Address TLVs .
Opaque Type
The value of this field MUST be set to TBA (by IANA).
Opaque ID
As defined in [RFC2370]
Advertising Router
As defined in [RFC2328].
LS Sequence Number
As defined in [RFC2328].
LS checksum
Bryskin, Berger [Page 6]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
As defined in [RFC2328].
Length
As defined in [RFC2328].
L1VPN TLV(s)
A single L1VPN Info TLV or one or more L1VPN PE Address TLVs
TE TLV
One TE TLV may be included in a L1VPN LSA containing a L1VPN
Info TLV. No TE TLVs are permitted when other L1VPN TLV types
are used.
3.2. L1VPN INFO TLV
The following TLVs are introduced:
Name: L1VPN IPv4 Info
Type: 1
Length: Variable
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1VPN TLV length | L1VPN TLV Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1VPN Globally unique identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE TE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| L1VPN Auto-Discovery Information |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV length
The length of the TLV in bytes, including the 4 bytes of
the TLV header.
L1VPN TLV Type
The type of the TLVs.
L1VPN Globally unique identifier
As defined in [L1VPN-BM].
Bryskin, Berger [Page 7]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
PE TE Address
Valid PE TE address: either TE Router ID specified in the
Router Address TLV or local numbered TE link ID specified in
the Local interface IP address sub-TLV of the Link TLV of the
TE LSA originated by the PE
L1VPN Auto-discovery information
As defined in [L1VPN-BM].
3.3. L1VPN PE Address TLV
Name: L1VPN IPv4 PE Address
Type: 2
Length: 8
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1VPN TLV length | L1VPN TLV Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE TE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV length
The length of the TLV in bytes, including the 4 bytes of
the TLV header.
L1VPN TLV Type
The type of the TLVs.
PE TE Address
A PE TE Address advertised by this router in a L1VPN Info.
4. L1VPN Info TLV Processing
PEs advertise local <CPI, PPI> tuples in L1VPN Opaque LSAs containing
a L1VPN Info TLV. (L1VPN Opaque LSAs containing a L1VPN Info TLV are
referred to as L1VPN Info LSAs.) Each PE MUST originate a separate
L1VPN Info LSA with AS flooding scope for each local CE-PE link. The
LSA MUST be originated once on the PE restart and every time when
there is a change in the PIT entry associated with a local CE-PE
link. The LSA MUST include a single L1VPN Info TLV and MAY include a
single TE Link TLV as per [RFC 3630] and [RFC 4203].
L1VPN Info LSAs are flooded to all PEs within the AS according to
[RFC 2370]. Every time a PE receives a new, removed or modified such
LSA, the PE MUST check whether it maintains a PIT associated with the
Bryskin, Berger [Page 8]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
L1VPN specified in the L1VPN Globally unique identifier field. If
this is the case (the appropriate PIT will be found if one or more
local CE-PE links that belong to the L1VPN are configured), the PE
SHOULD add, remove or modify the PIT entry associated with each of
the advertised CE-PE links accordingly. Thus, in the steady mode all
PEs associated with a particular L1VPN maintain identical local PITs
for the L1VPN. Note that in the case of a multi-area implementation,
the PE MUST also verify that the PE identified in the Info TLV is
valid based on matching L1VPN PE Address TLV being present in the
LSDB, see section 5.
4.1. Discussion and Example
The L1VPN auto-discovery mechanism described in this document does
not prevent a PE from applying any local policy with respect to PIT
management. For example, it should be possible to configure permanent
(static) PIT entries, blocking information carried in L1VPN LSAs that
are advertised by some remote PEs from making it to the PITs and so
forth.
The reason why it is required that the value specified in the PE TE
Address field of the L1VPN Info TLV matches a valid PE TE Router ID
or numbered TE Link ID is to ensure that CEs attached to this PE
could be resolved to the PE as it is known to the Traffic Engineering
Database (TED) and hence TE paths towards the CEs across the Provider
domain could be computed.
Let us consider example presented on Figure 2.
CE11 CE13
| |
CE22---PE1--------P------PE2
| |
CE15 PE3
|
CE24
Figure 2: Single area configuration
Let us assume that PE1 is connected to CE11 and CE15 in L1VPN1 and to
CE22 in L1VPN2; PE2 is connected to CE13 in L1VPN1; PE3 is connected
to CE24 in L1VPN2. In this configuration PE1 manages two PITs: PIT1
for L1VPN1 and PIT2 for L1VPN2; PE2 manages only PIT1, and PE3
manages only PIT2. PE1 originates three L1VPN Info LSAs each
containing a L1VPN Info TLV advertising links PE1-CE11, PE1-CE22 and
PE1-CE15 respectively. PE2 originates a single L1VPN Info LSA for
Bryskin, Berger [Page 9]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
link PE2-CE13 and PE3 originates a single L1VPN Info LSA for link
PE3-CE24. In the steady mode PIT1 on PE1 and PE3 will contain
information on links PE1-CE11, PE1-CE15 and PE2-CE13; PIT2 on PE1 and
PE2 will contain entries for links PE1-CE22 and PE3-CE24. Thus, all
PEs will learn about all remote PE-CE links for all L1VPNs supported
by PEs.
Note that P in this configuration does not have links connecting it
to any of L1VPNs. It neither originates L1VPN LSAs nor maintains any
PITs. However, it does participate in the flooding of all of the
L1VPN LSA and hence `maintains the LSAs in its LSDB. This is a cause
for scalability concerns and could prove to be problematic on large
networks.
5. L1VPN PE Address TLV Processing
A PE MUST advertise a L1VPN PE Address TLV for each PE TE Address
specified in L1VPN Info TLVs contained within L1VPN Info LSAs
originated by the PE. The L1VPN PE Address TLVs SHOULD be carried
within a single L1VPN LSA. (L1VPN LSAs containing L1VPN PE Address
TLV are referred to as L1VPN PE Address LSAs.) A L1VPN PE Address LSA
MUST be of the area flooding scope and MUST contain one or more L1VPN
PE Address TLVs.
The value specified in the PE TE Address field of the L1VPN PE
Address TLV MUST matche the value specified in the PE TE Address
field of the L1VPN Info TLV.
When an ABR receives a L1VPN PE Address LSA, it MUST re-originate the
contents of the LSA into the adjacent area(s). Prior to such a re-
origination, the ABR MUST verify that the value specified in the
Advertising Router field of the received LSA header does not match
the OSPF Router ID of one of the routers located in each of the
adjacent areas. The contents of the received LSA MUST NOT be re-
originated into any area with which such a match is found. The
consequence of this rule is that the contents of the received LSA is
never re-originated into the area over which the LSA was received.
As an optimization the ABR MAY combine multiple received such LSAs
and originate a single one containing multiple L1VPN PE Address TLVs.
An ABR SHOULD NOT copy any given L1VPN PE Address TLV from one or
more received LSA(s) into more than one LSA of its own injected into
any given adjacent area. For example, if an ABR receives two L1VPN PE
Address LSAs from two other ABRs containing the same L1VPN PE Address
TLV, the ABR should include the L1VPN PE Address TLV only to one (of
possibly many)LSAs that it originates into any of the adjacent areas.
Bryskin, Berger [Page 10]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
Whenever an ABR identifies that the originator (PE or another ABR) of
an L1VPN PE Address LSA that is currently installed in the ABR's LSDB
is not longer functioning (for example, the ABR cannot find a
sequence of the OSPF adjacencies connecting the ABR to the LSA
originator), it MUST remove any L1VPN PE Address TLVs advertised by
the faulted routing controller from all L1VPN PE Address LSAs
originated by the ABR. This action ensures that the L1VPN PE Address
TLV of the PE that went out of service is quickly purged out of LSDBs
of all routing controllers of the domain (including those located in
other areas), even if the PE (perhaps, because of the crash) has not
flushed out its LSAs before the exit.
A PE SHOULD validate L1VPN Info LSAs type using L1VPN PE Address LSAs
according to the following rule: a L1VPN Info LSA is considered to be
valid and could be used for updating the local PIT if and only if at
least one L1VPN PE Address LSA could be found in the local LSDB with
the value specified in the PE TE Address field of the L1VPN PE
Address TLV matching the value specified in the PE TE Address field
of the L1VPN Info TLV carried in the L1VPN Info LSA
5.1. Example
Let's consider the example presented on figure 3.
AREA1 >|< AREA 0 >|< AREA2
PE1-...-ABR1-...--ABR2--...-PE2
| | | |
-...--ABR4---...--ABR3--...---
Figure 3: Multi-area configuration
Suppose, PE2 originates a L1VPN PE Address LSA carrying a single
L1VPN PE Address TLV. Both ABR2 and ABR3 receive the LSA, originate
L1VPN PE Address LSAs (one each ABR) of their own and inject them
into Area 0. When ABR3 receives the LSA originated by ABR2 from Area
0 it notices that the LSA originator belongs to Area 2. Hence the
ABR3 will not originate a new LSA into Area 2. The same thing happens
when ABR3 receives the LSA originated by ABR2. When ABR1, however,
receives the LSA originated by either ABR2 or ABR3, it originates a
new L1VPN PE Address LSA , copies the L1VPN PE Address TLV from the
received LSA and injects the LSA into Area 1. That is how PE1
receives an LSA carrying the L1VPN PE Address TLV with the PE2
information. ABR4 performs the same operations as ABR1. Note that
ABR1 receives the LSA injected by ABR4 into Area 1; however, ABR1
does not re-originate the LSA back into Area 0 because the
Advertising Router field of the received LSA header contains the OSPF
Bryskin, Berger [Page 11]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
Router ID of ABR4, which belongs to Area 0. Likewise, ABR4 does not
re-originate into Area 0 the LSA originated by ABR1 in Area 1.
Suppose, now PE2 goes suddenly out of service. ABR2 will quickly
notice this because it would not be able to find a sequence of OSPF
adjacencies connecting itself to PE2. Therefore, ABR2 either
withdraws or modifies the L1VPN PE Address LSA it has previously
originated into Area 0, so that the new LSA will not carry the L1VPN
PE Address TLV associated with PE2. ASB3 performs the same operation
when it detects the lost of OSPF adjacency connectivity with PE2.
ABR1 notices that the LSAs originated by both ABR2 and ABR3 do not
carry the L1VPN PE Address TLV for PE2 anymore and updates
appropriately the L1VPN PE Address LSA that it sends into Area 1.
Finally, PE1 receives the update and finds out that it does not have
in its LSDB a L1VPN PE Address LSA containing L1VPN PE Address TLV
for PE2. Therefore, it can invalidate all L1VPN Info LSAs advertising
all PE2s CE-PE links.
6. Backward compatibility
Neither TLVs nor LSAs introduced in this document introduce any
interoperability issues. OSPF speakers that do not support L1VPN
auto-discovery application (Ps for example) just participate in the
L1VPN LSAs flooding process but should ignore the LSAs contents.
7. Security Considerations
The solution presented in this document describes how PEs dynamically
learn L1VPN specific information. Mechanisms to deliver the VPN
membership information to CEs are explicitly out of scope of this
document. Therefore, no new security issues are raised in this
document.
8. 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
Bryskin, Berger [Page 12]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
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.
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".
9. Acknowledgement
We would like to thank Adrian Farrel for his useful comments.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC2328] Moy, J., " OSPF Version 2 ", RFC 2328, April 1998.
[RFC2370] Coltun, R., " The OSPF Opaque LSA Option ", RFC 2730,
July 1998.
[RFC3630] Ktaz, D., Kompela, K., Yeung. D.., " Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September
2003.
[RFC4203] Kompela, K., Rekhter, Y. " OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)", RFC
4203, October 2005.
Bryskin, Berger [Page 13]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
[L1VPN-BM] Fedyk, D., Rekhter, Y. (Eds.), "Layer 1 VPN Basic
Mode", draft-fedyk-l1vpn-basic-mode-01.txt, January
2006, work in progress.
10.2. Informative References
[L1VPN-FRMWK] Tomonori Takeda, et al., " Framework and
Requirements for Layer 1 Virtual Private Networks",
draft-ietf-l1vpn-framework-00.txt, August 2005, work
in progress
[L1VPN-BGP] Ould-Brahim H., Fedyk D., Rekhter, Y., "BGP-based Auto-
Discovery for L1VPNs ",
draft-ouldbrahim-l1vpn-bgp-auto-discovery- 00.txt
(work in progress)
[LEXICOGRAPHY] Bryskin, I., Farrel, A "A Lexicography for the
Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within The Context of
the ITU-T's Automatically Switched Optical Network
(ASON) Architecture", (work in progress)
11. Authors' Addresses
Igor Bryskin
Movaz Networks, Inc.
7926 Jones Branch Drive
Suite 615
McLean, VA - 22102
Email: ibryskin@movaz.com
Lou Berger
LabN Consulting, LLC
Email: lberger@labn.net
12. Auto-Discovery Information
[The following is expected to be included in draft-fedyk-l1vpn-basic-
mode-01.txt]
Auto-Discovery Information
This section provides the information that is carried by any auto-
discovery mechanism, and is used to dynamically populate a PIT. The
information provides a single <CPI, PPI> mapping. Each auto-
Bryskin, Berger [Page 14]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
discovery mechanism will define the method(s) by which multiple <CPI,
PPI> mappings are communicated, as well as invalidated.
The encoding of the auto-discovery information uses BGP address
family identifiers (AFIs), and defines a new AFI for L1VPN (to be
assigned by the IANA).
The format of encoding a single <PPI, CPI> tuple is:
+---------------------------------------+
| Length (1 octet) |
+---------------------------------------+
| PPI AFI (2 octets) |
+---------------------------------------+
| PPI Length (1 octet) |
+---------------------------------------+
| PPI (variable) |
+---------------------------------------+
| CPI AFI (2 octets) |
+---------------------------------------+
| CPI (length) |
+---------------------------------------+
| CPI (variable) |
+---------------------------------------+
Figure 4: Auto-Discovery Information
The use and meaning of these fields are as follows:
Length:
A one octet field whose value indicates the length of
the <PPI, CPI> Information tuple in octets.
PPI AFI:
A two octets field whose value indicates address
family identifier of PPI
PPI Length:
A one octet field whose value indicates the length of
of the PPI field
PPI field:
Bryskin, Berger [Page 15]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
A variable length field that contains the value of
the PPI (either an address or <port index,
address> tuple
CPI AFI field:
A two octets field whose value indicates address
family of the CPI.
CPI Length:
A once octet field whose value indicates the
length of the CPI field.
CPI (variable):
A variable length field that contains the CPI
value (either an address or <port index, address>
tuple.
<PPI, CPI> tuples must also be associated with one or more globally
unique identifiers associated with a particular VPN. A globally
unique identifier can encode a VPN-ID, a route target, or any other
globally unique identifier. In this document we specify a generic
encoding format for the globally unique identifier common to all the
auto-discovery mechanisms. However, each auto-discovery mechanism
will define the specific method(s) by which the encoding is
distributed and the association with a <PPI, CPI> tuple is made. The
encoding of the globally unique identifier associated with the VPN
is:
+------------------------------------------------+
| L1vpn Globally unique identifier (8 octets) |
+------------------------------------------------+
Figure 5: Auto-Discovery Globally unique identifier Format
13. Full Copyright Statement
Copyright (C) The Internet Society (2006). 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 AND THE INTERNET
Bryskin, Berger [Page 16]
Internet Draft draft-bryskin-l1vpn-ospf-auto-discovery-00.txtFebruary 2006
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.
14. 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.
Bryskin, Berger [Page 17]
Generated on: Thu Feb 16 17:37:02 EST 2006