summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5252.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5252.txt')
-rw-r--r--doc/rfc/rfc5252.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc5252.txt b/doc/rfc/rfc5252.txt
new file mode 100644
index 0000000..856c6b9
--- /dev/null
+++ b/doc/rfc/rfc5252.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group I. Bryskin
+Request for Comments: 5252 ADVA Optical Networking
+Category: Standards Track L. Berger
+ LabN Consulting, LLC
+ July 2008
+
+
+ OSPF-Based Layer 1 VPN Auto-Discovery
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+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 the existence of each other, and attributes
+ of configured customer edge (CE) links and their associations with
+ L1VPNs. This document builds on the L1VPN framework and requirements
+ and provides a L1VPN basic mode auto-discovery mechanism.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Overview ...................................................2
+ 1.2. Terminology ................................................3
+ 1.3. Conventions Used in This Document ..........................4
+ 2. L1VPN LSA and Its TLVs ..........................................4
+ 2.1. L1VPN LSA ..................................................4
+ 2.2. L1VPN INFO TLV .............................................6
+ 3. L1VPN LSA Advertising and Processing ............................7
+ 3.1. Discussion and Example .....................................7
+ 4. Backward Compatibility ..........................................8
+ 5. Security Considerations .........................................9
+ 6. IANA Considerations .............................................9
+ 7. Acknowledgments .................................................9
+ 8. References ......................................................9
+ 8.1. Normative References .......................................9
+ 8.2. Informative References ....................................10
+
+
+
+
+
+
+Bryskin & Berger Standards Track [Page 1]
+
+RFC 5252 OSPF-Based L1VPN Auto-Discovery July 2008
+
+
+1. Introduction
+
+1.1. Overview
+
+ The framework for Layer 1 VPNs is described in [RFC4847]. Basic mode
+ operation is further defined in [RFC5251]. The L1VPN Basic Mode
+ (L1VPN-BM) document [RFC5251] 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 L1VPN connections. 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 [RFC5195] 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.
+
+
+
+Bryskin & Berger Standards Track [Page 2]
+
+RFC 5252 OSPF-Based L1VPN Auto-Discovery July 2008
+
+
+ The approach used in this document to provide OSPF-based L1VPN auto-
+ discovery uses a new type of Opaque Link State Advertisement (LSA)
+ that 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 referred to as the L1VPN Info TLV. The
+ L1VPN LSA may also carry Traffic Engineering (TE) TLVs; see [RFC3630]
+ and [RFC4203].
+
+1.2. 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 [RFC2328], [RFC5250], and [RFC3630]. In particular,
+ the following terms:
+
+ L1VPN - Layer 1 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 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]
+
+RFC 5252 OSPF-Based L1VPN Auto-Discovery July 2008
+
+
+1.3. 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].
+
+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 [RFC5250].
+
+ Opaque Type
+ The value of this field MUST be set to 5.
+
+
+
+
+
+Bryskin & Berger Standards Track [Page 4]
+
+RFC 5252 OSPF-Based L1VPN Auto-Discovery July 2008
+
+
+ Opaque ID
+ As defined in [RFC5250].
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryskin & Berger Standards Track [Page 5]
+
+RFC 5252 OSPF-Based L1VPN Auto-Discovery July 2008
+
+
+2.2. L1VPN INFO TLV
+
+ The following TLV is 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 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 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 [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 0.
+
+
+
+Bryskin & Berger Standards Track [Page 6]
+
+RFC 5252 OSPF-Based L1VPN Auto-Discovery July 2008
+
+
+ L1VPN Auto-discovery information
+ As defined in [RFC5251].
+
+ Padding
+ A field of variable length and of sufficient size to ensure that
+ the TLV is aligned on a 4-byte boundary. This field is only
+ required when the L1VPN Auto-discovery information field is not
+ 4-byte aligned. This field MUST be less than 4 bytes long, and
+ MUST NOT be present when the size of the L1VPN Auto-discovery
+ information field is 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-to-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-to-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-to-PE link. Note that because CEs
+ are outside of the provider TE domain, the attributes of CE-to-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 therefore are
+ flooded to all PEs within the AS according to [RFC5250]. 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-to-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-to-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. An example of such a local policy would be the ability
+ to configure permanent (static) PIT entries. Another example would
+
+
+
+
+Bryskin & Berger Standards Track [Page 7]
+
+RFC 5252 OSPF-Based L1VPN Auto-Discovery July 2008
+
+
+ be the ability to ignore information carried in L1VPN LSAs advertised
+ by a specific TE.
+
+ 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-to-CE links for all L1VPNs supported by PEs.
+
+ Note that P in this configuration does not have links connecting it
+ to any 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.
+
+4. Backward Compatibility
+
+ Neither the TLV nor the LSA introduced in this document present any
+ interoperability issues. Per [RFC5250], OSPF speakers that do not
+ support the L1VPN auto-discovery application (Ps for example) just
+
+
+
+
+Bryskin & Berger Standards Track [Page 8]
+
+RFC 5252 OSPF-Based L1VPN Auto-Discovery July 2008
+
+
+ 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
+ [RFC5250]. 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 where 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.
+ IANA has made the assignment in the form:
+
+ Value Opaque Type Reference
+ ------- ----------- ---------
+ 5 L1VPN LSA [RFC5252]
+
+7. Acknowledgments
+
+ We would like to thank Adrian Farrel and Anton Smirnov for their
+ useful comments.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+ [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
+ (TE) Extensions to OSPF Version 2", RFC 3630, September
+ 2003.
+
+
+
+Bryskin & Berger Standards Track [Page 9]
+
+RFC 5252 OSPF-Based L1VPN Auto-Discovery July 2008
+
+
+ [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
+ in Support of Generalized Multi-Protocol Label Switching
+ (GMPLS)", RFC 4203, October 2005.
+
+ [RFC5250] Berger, L., Bryskin, I., and A. Zinin, "The OSPF Opaque
+ LSA Option", RFC 5250, July 2008.
+
+ [RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D.,
+ Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC
+ 5251, July 2008.
+
+8.2. Informative References
+
+ [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
+ Digital Signatures", RFC 2154, June 1997.
+
+ [RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1
+ Virtual Private Networks", RFC 4847, April 2007.
+
+ [RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based
+ Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryskin & Berger Standards Track [Page 10]
+
+RFC 5252 OSPF-Based L1VPN Auto-Discovery July 2008
+
+
+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.
+
+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 Standards Track [Page 11]
+