Internet Draft Lou Berger (LabN Consulting, LLC)
Category: Experimental
Expiration Date: February 8, 2009
August 8, 2008
OSPFv3 Based Layer 1 VPN Auto-Discovery
draft-ietf-l1vpn-ospfv3-auto-discovery-02.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 February 8, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document defines an Open Shortest Path First (OSPF) version 3
based Layer-1 Virtual Private Network (L1VPN) auto-discovery
mechanism. This document parallels the existing OSPF version 2 L1VPN
auto-discovery mechanism. The notable functional difference is the
support of IPv6.
Berger Experimental [Page 1]
Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt August 8, 2008
Table of Contents
1 Introduction .............................................. 3
1.1 Terminology ............................................... 3
1.2 Overview .................................................. 4
2 OSPFv3 L1VPN LSA and its TLVs ............................. 5
2.1 OSPFv3 L1VPN LSA .......................................... 5
2.2 L1VPN IPv6 INFO TLV ....................................... 6
3 OSPFv3 L1VPN LSA Advertising and Processing ............... 8
4 Backward Compatibility .................................... 8
5 Security Considerations ................................... 9
6 IANA Considerations ....................................... 9
7 Acknowledgment ............................................ 9
8 References ................................................ 9
8.1 Normative References ...................................... 9
8.2 Informative References .................................... 10
9 Authors' Addresses ........................................ 10
10 Full Copyright Statement .................................. 10
11 Intellectual Property ..................................... 11
Berger Experimental [Page 2]
Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt August 8, 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 [RFC5251]. The reader of this document should also be
familiar with [RFC5340], [OSPFv3-TE], and [RFC5252]. 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
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
Berger Experimental [Page 3]
Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt August 8, 2008
1.2. Overview
The framework for Layer 1 VPNs is described in [RFC4847]. Basic mode
operation is further defined in [RFC5251]. [RFC5251] identifies the
information that is necessary to map customer information (port
identifiers) to provider information (identifiers). It also states
that this mapping information may be provided via provisioning or via
an auto-discovery mechanism. [RFC5252] provides such an auto-
discovery mechanism using Open Shortest Path First (OSPF) version 2.
This document provides the same functionality using of OSPF version 3
and adds support for IPv6.
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 Layer 1 VPNs. 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
The approach used in this document to provide OSPFv3 based L1VPN
auto-discovery uses a new type of Link State Advertisement (LSA)
which is referred to as an OSPFv3 L1VPN LSA. The OSPFv3 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.
Berger Experimental [Page 4]
Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt August 8, 2008
The OSPFv3 L1VPN LSA may also carry Traffic Engineering (TE) TLVs,
see [RFC3630], [RFC4203], and [OSPFv3-TE].
2. OSPFv3 L1VPN LSA and its TLVs
This section defines the OSPFv3 L1VPN LSA and its TLVs.
2.1. OSPFv3 L1VPN LSA
The format of a OSPFv3 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 | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L1VPN Info TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Link TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LS age
As defined in [RFC5340].
LS type
As defined in [RFC5340]. The U-bit MUST be set to 1, and the
S1 and S2 bits MUST be set to indicate either area or AS scoping.
The LSA Function Code portion of this field MUST be set to TBA
(by IANA), i.e., the OSPFv3 L1VPN LSA.
Advertising Router
As defined in [RFC5340].
LS Sequence Number
As defined in [RFC5340].
Berger Experimental [Page 5]
Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt August 8, 2008
LS checksum
As defined in [RFC5340].
Length
As defined in [RFC5340].
L1VPN Info TLV
A single L1VPN Info TLV, as defined in section 2.2 of [RFC5252]
or section 2.2 of this document, 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. If no L1VPN Info TLV is
present, the LSA is processed (and flooded) as normal, but the
L1VPN PIT table MUST NOT be modified in any way.
TE Link TLV
A single TE Link TLV MAY be included in an OSPFv3 L1VPN LSA.
When an L1VPN IPv4 Info TLV is present, a single TE Link TLV as
defined in [RFC3630] and [RFC4203] MAY be included. When an
L1VPN IPv6 Info TLV is present, a single TE Link TLV as defined
in [OSPFv3-TE] MAY be included.
2.2. L1VPN IPv6 INFO TLV
The following TLV is introduced:
Name: L1VPN IPv6 Info
Type: 2
Length: Variable
Berger Experimental [Page 6]
Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt August 8, 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 (see above).
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 [RFC5251].
PE TE Address
This field MUST carry an address that has been advertised by
the LSA originator per [OSPFv3-TE] 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 [RFC5340] in a
Router LSA. When a numbered link is represented, this field
MUST be set to zero (0).
L1VPN Auto-discovery information
As defined in [RFC5251].
Berger Experimental [Page 7]
Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt August 8, 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. OSPFv3 L1VPN LSA Advertising and Processing
PEs advertise local <CPI, PPI> tuples in OSPFv3 L1VPN LSAs containing
L1VPN Info TLVs. Each PE MUST originate a separate OSPFv3 L1VPN LSA
with area or AS flooding scope, based on configuration, 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. 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
[OSPFv3-TE]. 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.
Every time a PE receives a new, removed, or modified OSPFv3 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.
4. Backward Compatibility
Neither the TLV nor the LSA introduced in this document present any
interoperability issues. Per [RFC5340] and due to the U-bit being
set, OSPFv3 speakers that do not support the OSPFv3 L1VPN LSA (Ps for
example) just participate in the LSAs flooding process but should
ignore the LSAs contents.
Berger Experimental [Page 8]
Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt August 8, 2008
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 [RFC5340].
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 approach similar to the experimental extension to
OSPF, see [RFC2154], which supports the signing and authentication of
LSAs.
6. IANA Considerations
Section 2.1 of this document requests the assignment of an OSPFv3 LSA
Function Code, see http://www.iana.org/assignments/ospfv3-parameters.
IANA is requested to make an assignment in the form:
Value OSPFv3 LSA type function Type Reference
------- ----------------------------- ---------
TBA OSPFv3 L1VPN LSA [this document]
A value of 13 is suggested for TBA.
7. Acknowledgment
This document was created at the request of Pasi Eronen. Adrian
Farrel and Acee Lindem provided valuable reviews of this draft.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
Berger Experimental [Page 9]
Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt August 8, 2008
[RFC5340] R. Coltun, D. Ferguson, J. Moy, "OSPF for IPv6",
RFC 5340.
[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.
[RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D.,
Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode",
RFC 5251, June 2008.
[RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN
Auto-Discovery", RFC 5252, June 2008.
[OSPFv3-TE] K. Ishiguro, T. Takada, "Traffic Engineering
Extensions to OSPF version 3", work in progress,
draft-ietf-ospf-ospfv3-traffic
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.
9. Authors' Addresses
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
Berger Experimental [Page 10]
Internet-Draft draft-ietf-l1vpn-ospfv3-auto-discovery-02.txt August 8, 2008
"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.
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).
Berger Experimental [Page 11]
Generated on: Fri Aug 8 09:53:09 EDT 2008
