One document matched: draft-ietf-l1vpn-ospf-auto-discovery-06.txt
Differences from draft-ietf-l1vpn-ospf-auto-discovery-05.txt
Internet Draft Igor Bryskin (ADVA Optical Networking)
Category: Standards Track Lou Berger (LabN Consulting, LLC)
Expiration Date: November 13, 2008
May 13, 2008
OSPF Based Layer 1 VPN Auto-Discovery
draft-ietf-l1vpn-ospf-auto-discovery-06.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
This Internet-Draft will expire on November 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document defines an Open Shortest Path First (OSPF) based
Layer-1 Virtual Private Network (L1VPN) auto-discovery mechanism.
This mechanism enables provider edge (PE) devices using OSPF to
dynamically learn about existence of each other, and attributes of
configured customer edge (CE) links and their associations with
L1VPNs. This document builds on L1VPN framework and requirements,
and provides a L1VPN basic mode auto-discovery mechanism.
Bryskin & Berger Standards Track [Page 1]
Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt May 13, 2008
Table of Contents
1 Introduction .............................................. 3
1.1 Terminology ............................................... 3
1.2 Overview .................................................. 4
2 L1VPN LSA and its TLVs .................................... 5
2.1 L1VPN LSA ................................................. 5
2.2 L1VPN INFO TLV ............................................ 6
3 L1VPN LSA Advertising and Processing ...................... 8
3.1 Discussion and Example .................................... 8
4 Backward Compatibility .................................... 10
5 Security Considerations ................................... 10
6 IANA Considerations ....................................... 10
7 Acknowledgment ............................................ 11
8 References ................................................ 11
8.1 Normative References ...................................... 11
8.2 Informative References .................................... 11
9 Authors' Addresses ........................................ 12
10 Full Copyright Statement .................................. 12
11 Intellectual Property ..................................... 12
Bryskin & Berger Standards Track [Page 2]
Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt May 13, 2008
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. Introduction
1.1. Terminology
The reader of this document should be familiar with the terms used in
[RFC4847] and [L1VPN-BM]. The reader of this document should also be
familiar with [RFC2328], [2370BIS], and [RFC3630]. 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 PR 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
LSA - OSPF link State Advertisement.
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 Standards Track [Page 3]
Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt May 13, 2008
1.2. Overview
The framework for Layer 1 VPNs is described in [RFC4847]. 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 Open
Shortest Path First (OSPF) version 2. Use of OSPF version 3 and
support for IPv6 are out of scope of this document and will be
defined separately.
Figure 1 shows the L1VPN basic service being supported using OSPF
based L1VPN auto-discovery. This figure shows two PE routers
interconnected over a GMPLS backbone. Each PE is attached to three
CE devices belonging to three different Cons. In this network, OSPF
is used to provide the VPN membership, port mapping and related
information required to support basic mode operation.
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
See [L1VPN-BGP] for a parallel L1VPN auto-discovery that uses BGP.
The OSPF approach described in this document is particularly useful
in networks where BGP is not typically used.
The approach used in this document to provide OSPF based L1VPN auto-
Bryskin & Berger Standards Track [Page 4]
Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt May 13, 2008
discovery uses a new type of Opaque Link State Advertisement (LSA)
which is referred to as an L1VPN LSA. The L1VPN LSA carries
information in TLV (type, length, value) structures. An L1VPN
specific TLV is defined below to propagate VPN membership and port
information. This TLV is is referred to as the L1VPN Info TLV. The
L1VPN LSA may also carry Traffic Engineering (TE) TLVs, see [RFC3630]
and [RFC4203].
2. L1VPN LSA and its TLVs
This section defines the L1VPN LSA and its TLVs.
2.1. L1VPN 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 Info TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Link TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LS age
As defined in [RFC2328]
Options
As defined in [RFC2328].
LS Type
This field MUST be set to 11, i.e., an Autonomous System (AS)
scoped Opaque LSA [2370BIS].
Bryskin & Berger Standards Track [Page 5]
Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt May 13, 2008
Opaque Type
The value of this field MUST be set to TBA (by IANA).
Opaque ID
As defined in [2370BIS].
Advertising Router
As defined in [RFC2328].
LS Sequence Number
As defined in [RFC2328].
LS checksum
As defined in [RFC2328].
Length
As defined in [RFC2328].
L1VPN Info TLV
A single TLV, as defined in section 3.2, MUST be present.
If more than one L1VPN Info TLV is present, only the first TLV is
processed and the others MUST be ignored on receipt.
TE Link TLV
A single TE Link TLV (as defined in [RFC3630] and [RFC4203])
MAY be included in a L1VPN LSA
2.2. L1VPN INFO TLV
The following TLV is introduced:
Name: L1VPN IPv4 Info
Type: 1
Length: Variable
Bryskin & Berger Standards Track [Page 6]
Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt May 13, 2008
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 Type | L1VPN TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1VPN Globally Unique Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PE TE Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Local Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| L1VPN Auto-Discovery Information |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .| Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L1VPN TLV Type
The type of the TLV.
TLV Length
The length of the TLV in bytes, excluding the four (4) bytes
of the TLV header and, if present, the length of the Padding
field.
L1VPN Globally Unique Identifier
As defined in [L1VPN-BM].
PE TE Address
This field MUST carry an address that has been advertised by
the LSA originator per [RFC3630] and is either the Router Address
TLV or Local interface IP address link sub-TLV. It will
typically carry the TE Router Address.
Link Local Identifier
This field is used to support unnumbered links. When an
unnumbered PE TE link is represented, this field MUST contain
a value advertised by the LSA originator per [RFC4203] in a
Link Local/Remote Identifiers link sub-TLV. When a numbered
link is represented, this field MUST be set to zero (0).
L1VPN Auto-discovery information
As defined in [L1VPN-BM].
Bryskin & Berger Standards Track [Page 7]
Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt May 13, 2008
Padding
A field of variable length and of sufficient size to ensure
that the TLV is aligned on a four (4) byte boundary. This
field is only required when the L1VPN Auto-discovery
information field is not four (4) byte aligned. This field
MUST be less than four (4) bytes long, and MUST NOT be present
when the size of L1VPN Auto-discovery information field is
four (4) byte aligned.
3. L1VPN LSA Advertising and Processing
PEs advertise local <CPI, PPI> tuples in L1VPN LSAs containing L1VPN
Info TLVs. Each PE MUST originate a separate L1VPN LSA with AS
flooding scope for each local CE-PE link. The LSA MUST be originated
each time a PE restarts and every time 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
[RFC3630] and [RFC4203]. The TE Link TLV carries TE attributes of
the associated CE-PE link. Note that because CEs are outside of the
provider TE domain, the attributes of CE-PE links are not advertised
via normal OSPF-TE procedures as described in [RFC3630] and
[RFC4203]. If more than one L1VPN Info TLVs and/or TE Link TLVs are
found in the LSA, the subsequent TLVs SHOULD be ignored by the
receiving PEs.
L1VPN LSAs are of AS-scope (LS type is set to 11) and therefor are
flooded to all PEs within the AS according to [2370BIS]. Every time a
PE receives a new, removed or modified L1VPN LSA, the PE MUST check
whether it maintains a PIT associated with the 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. (An implementation MAY choose to not remove or
modify the PIT according to local policy or management directives.)
Thus, in the normal steady-state case, all PEs associated with a
particular L1VPN will have identical local PITs for an L1VPN.
3.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 of information carried in L1VPN LSAs
that are advertised by some remote PEs from making it to the PITs.
Bryskin & Berger Standards Track [Page 8]
Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt May 13, 2008
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 can
be resolved to the PE as it is known to the Traffic Engineering
Database (TED) and hence TE paths toward the CEs across the Provider
domain can be computed.
Let us consider the example presented in 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 LSAs, each containing a
L1VPN Info TLV advertising links PE1-CE11, PE1-CE22 and PE1-CE15
respectively. PE2 originates a single L1VPN LSA for link PE2-CE13 and
PE3 originates a single L1VPN LSA for link PE3-CE24. In steady state
the 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 LSAs and hence maintains the LSAs in its LSDB. This is a cause
for scalability concerns and could prove to be problematic in large
networks.
Bryskin & Berger Standards Track [Page 9]
Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt May 13, 2008
4. Backward Compatibility
Neither the TLV nor the LSA introduced in this document present any
interoperability issues. Per [2370BIS], OSPF speakers that do not
support the L1VPN auto-discovery application (Ps for example) just
participate in the L1VPN LSAs flooding process but should ignore the
LSAs contents.
5. Security Considerations
The approach 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, the security issues raised in this document are
limited to within the OSPF domain.
This defined approach reuses mechanisms defined in [RFC2328] and
[2370BIS]. Therefore the same security approaches and considerations
apply to this approach. OSPF provides several security mechanisms
that can be applied. Specifically, OSPF supports multiple types of
authentication, limits the frequency of LSA origination and
acceptance, and provides techniques to avoid and limit impact
database overflow. In cases were end-to-end authentication is
desired, OSPF's neighbor-to-neighbor authentication approach can be
augmented with an experimental extension to OSPF, see [RFC2154],
which supports the signing and authentication of LSAs.
6. IANA Considerations
This document requests the assignment of an OSPF Opaque LSA type, see
http://www.iana.org/assignments/ospf-opaque-types. IANA is requested
to make an assignment in the form:
Value Opaque Type Reference
------- ----------- ---------
TBA L1VPN LSA [this document]
A value of 4 is suggested for TBA.
Bryskin & Berger Standards Track [Page 10]
Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt May 13, 2008
7. Acknowledgment
We would like to thank Adrian Farrel and Anton Smirnov for their
useful comments.
8. References
8.1. Normative References
[2370BIS] Berger, L., Bryskin, I., Zinin, A., "The OSPF Opaque LSA
Option", work in progress, draft-ietf-ospf-rfc2370bis,
May 8, 2008.
[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.
[RFC3630] Katz, 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.
[L1VPN-BM] Fedyk, D., Rekhter, Y. (Eds.), "Layer 1 VPN Basic
Mode", draft-fedyk-l1vpn-basic-mode, work in progress.
8.2. Informative References
[RFC2154] Murphy, S., Badger, M., Wellington, B., "OSPF with
Digital Signatures", RFC 2154, June 1997.
[RFC4847] Tomonori Takeda, Ed., "Framework and Requirements
for Layer 1 Virtual Private Networks", RFC 4847,
April 2007.
[L1VPN-BGP] Ould-Brahim H., Fedyk D., Rekhter, Y.,
"BGP-based Auto-Discovery for L1VPNs",
draft-ietf-l1vpn-bgp-auto-discovery, work in progress.
Bryskin & Berger Standards Track [Page 11]
Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt May 13, 2008
9. Authors' Addresses
Igor Bryskin
ADVA Optical Networking Inc
7926 Jones Branch Drive
Suite 615
McLean, VA - 22102
Email: ibryskin@advaoptical.com
Lou Berger
LabN Consulting, LLC
Email: lberger@labn.net
10. Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
11. 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.
Bryskin & Berger Standards Track [Page 12]
Internet-Draft draft-ietf-l1vpn-ospf-auto-discovery-06.txt May 13, 2008
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.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Bryskin & Berger Standards Track [Page 13]
Generated on: Tue May 13 11:24:17 EDT 2008
| PAFTECH AB 2003-2026 | 2026-04-23 11:40:07 |