Network Working Group I. Bryskin
Request for Comments: 5252 ADVA Optical Networking
Category: Standards Track L. Berger
LabN Consulting, LLC
July 2008
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
基于OSPF的第1层VPN自动发现
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
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.
本文档定义了基于开放最短路径优先（OSPF）的第1层虚拟专用网络（L1VPN）自动发现机制。此机制使使用OSPF的提供商边缘（PE）设备能够动态了解彼此的存在、配置的客户边缘（CE）链路的属性及其与L1VPN的关联。本文档以L1VPN框架和要求为基础，并提供了L1VPN基本模式自动发现机制。
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
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
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.
[RFC4847]中描述了第1层VPN的框架。[RFC5251]中进一步定义了基本模式操作。L1VPN基本模式（L1VPN-BM）文档[RFC5251]确定了将客户信息（端口标识符）映射到提供商信息（标识符）所需的信息。它还指出，可以通过供应或自动发现机制提供此映射信息。本文档使用开放最短路径优先（OSPF）版本2提供了这样一种自动发现机制。OSPF版本3的使用和对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 L1VPN connections. In this network, OSPF is used to provide the VPN membership, port mapping, and related information required to support basic mode operation.
图1显示了使用基于OSPF的L1VPN自动发现支持的L1VPN基本服务。此图显示了通过GMPLS主干互连的两个PE路由器。每个PE连接到属于三个不同L1VPN连接的三个CE设备。在该网络中，OSPF用于提供支持基本模式操作所需的VPN成员资格、端口映射和相关信息。
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 |
+--------+ | | | | | | | | +--------+
| +-----+ | | +----------+ |
+---------+ +--------------+
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
图1:L1VPN的OSPF自动发现
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.
有关使用BGP的并行L1VPN自动发现，请参阅[RFC5195]。本文档中描述的OSPF方法在通常不使用BGP的网络中特别有用。
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].
本文档中用于提供基于OSPF的L1VPN自动发现的方法使用了一种称为L1VPN LSA的新型不透明链路状态公告（LSA）。L1VPN LSA以TLV（类型、长度、值）结构承载信息。下面定义了L1VPN特定的TLV，以传播VPN成员资格和端口信息。此TLV称为L1VPN信息TLV。L1VPN LSA还可以承载流量工程（TE）TLV；参见[RFC3630]和[RFC4203]。
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:
本文件的读者应熟悉[RFC4847]和[RFC5251]中使用的术语。本文件的读者还应熟悉[RFC2328]、[RFC5250]和[RFC3630]。特别是以下术语：
L1VPN - Layer 1 Virtual Private Network
L1VPN-第1层虚拟专用网络
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
CE-直接连接到提供商网络的客户（边缘）网络元件（终止到一个或多个PE的一个或多个链路）；它还连接到一个或多个Cs和/或其他CE
C - Customer network element that is not connected to the provider network but is connected to one or more other Cs and/or CEs
C-未连接到提供商网络但连接到一个或多个其他Cs和/或CE的客户网元
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
PE-直接连接到一个或多个客户网络的提供商（边缘）网元（终止到与相同或不同L1VPN关联的一个或多个CE的一个或多个链路）；它还连接到一个或多个Ps和/或其他PE
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
P-未直接连接到任何客户网络的提供商（核心）网元；P连接到一个或多个其他Ps和/或PE
LSA - OSPF link State Advertisement
LSA-OSPF链路状态广告
LSDB - Link State Database: a data structure supported by an IGP speaker
链路状态数据库：IGP扬声器支持的数据结构
PIT - Port Information Table
PIT-端口信息表
CPI - Customer Port Identifier
CPI-客户端口标识符
PPI - Provider Port Identifier
PPI-提供程序端口标识符
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section defines the L1VPN LSA and its TLVs.
本节定义L1VPN LSA及其TLV。
The format of a L1VPN LSA is as follows:
L1VPN LSA的格式如下所示：
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 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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].
LS年龄定义见[RFC2328]。
Options As defined in [RFC2328].
[RFC2328]中定义的选项。
LS Type This field MUST be set to 11, i.e., an Autonomous System (AS) scoped Opaque LSA [RFC5250].
LS Type此字段必须设置为11，即自治系统（AS）作用域不透明LSA[RFC5250]。
Opaque Type The value of this field MUST be set to 5.
不透明类型此字段的值必须设置为5。
Opaque ID As defined in [RFC5250].
[RFC5250]中定义的不透明ID。
Advertising Router As defined in [RFC2328].
[RFC2328]中定义的广告路由器。
LS Sequence Number As defined in [RFC2328].
[RFC2328]中定义的LS序列号。
LS checksum As defined in [RFC2328].
[RFC2328]中定义的LS校验和。
Length As defined in [RFC2328].
[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.
L1VPN信息TLV必须存在第3.2节中定义的单个TLV。如果存在多个L1VPN信息TLV，则仅处理第一个TLV，其他TLV在收到时必须忽略。
TE Link TLV A single TE Link TLV (as defined in [RFC3630] and [RFC4203]) MAY be included in a L1VPN LSA.
TE链路TLV单个TE链路TLV（如[RFC3630]和[RFC4203]中所定义）可包括在L1VPN LSA中。
The following TLV is introduced:
介绍了以下TLV：
Name: L1VPN IPv4 Info Type: 1 Length: Variable
名称：L1VPN IPv4信息类型：1长度：变量
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
L1VPN TLV类型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.
TLV长度TLV的长度（以字节为单位），不包括TLV标头的4个字节以及填充字段的长度（如果存在）。
L1VPN Globally Unique Identifier As defined in [RFC5251].
[RFC5251]中定义的L1VPN全局唯一标识符。
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.
PE TE地址此字段必须包含LSA发起者根据[RFC3630]公布的地址，并且是路由器地址TLV或本地接口IP地址链路子TLV。它通常携带TE路由器地址。
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.
链接本地标识符此字段用于支持未编号的链接。当表示未编号的PE TE链路时，此字段必须包含LSA发起人根据链路本地/远程标识符链路子TLV中的[RFC4203]公布的值。表示带编号的链接时，此字段必须设置为0。
L1VPN Auto-discovery information As defined in [RFC5251].
[RFC5251]中定义的L1VPN自动发现信息。
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.
填充长度可变且大小足够的字段，以确保TLV在4字节边界上对齐。仅当L1VPN自动发现信息字段未对齐4字节时，才需要此字段。此字段的长度必须小于4字节，并且当L1VPN自动发现信息字段的大小为4字节对齐时，此字段不得出现。
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.
PE在包含L1VPN信息TLV的L1VPN LSA中公布本地<CPI，PPI>元组。每个PE必须为每个本地CE-to-PE链路创建一个单独的L1VPN LSA，并具有AS泛洪作用域。每次PE重新启动时，以及每次与本地CE-to-PE链路相关的PIT入口发生变化时，都必须发起LSA。根据[RFC3630]和[RFC4203]，LSA必须包括单个L1VPN信息TLV，并且可以包括单个TE链路TLV。TE链路TLV携带相关CE到PE链路的TE属性。请注意，由于CE位于提供商TE域之外，因此CE到PE链路的属性不会通过[RFC3630]和[RFC4203]中所述的正常OSPF-TE过程公布。如果在LSA中发现多个L1VPN信息TLV和/或TE链路TLV，则接收PE应忽略后续TLV。
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.
L1VPN LSA属于AS范围（LS类型设置为11），因此根据[RFC5250]的规定，L1VPN LSA将被淹没到AS内的所有PE。每次PE收到新的、删除的或修改的L1VPN LSA时，PE必须检查是否维护与L1VPN全局唯一标识符字段中指定的L1VPN关联的PIT。如果是这种情况（如果配置了属于L1VPN的一个或多个本地CE-to-PE链路，将找到相应的PIT），则PE应相应地添加、删除或修改与每个播发的CE-to-PE链路关联的PIT条目。（实施可能会根据本地策略或管理指令选择不删除或修改PIT。）因此，在正常稳态情况下，与特定L1VPN相关的所有PE将具有与L1VPN相同的本地PIT。
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
本文档中描述的L1VPN自动发现机制不会阻止PE应用与PIT管理有关的任何本地策略。这种本地策略的一个例子是能够配置永久（静态）PIT条目。另一个例子是
be the ability to ignore information carried in L1VPN LSAs advertised by a specific TE.
能够忽略特定TE公布的L1VPN LSA中携带的信息。
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.
要求L1VPN信息TLV的PE TE地址字段中指定的值与有效的PE TE路由器ID或编号的TE链路ID匹配的原因是为了确保连接到此PE的CE可以解析为PE，因为它是流量工程数据库（TED）已知的因此，可以计算跨提供者域的通向CE的TE路径。
Let us consider the example presented in Figure 2.
让我们考虑图2中给出的例子。
CE11 CE13
| |
CE22---PE1--------P------PE2
| |
CE15 PE3
|
CE24
CE11 CE13
| |
CE22---PE1--------P------PE2
| |
CE15 PE3
|
CE24
Figure 2: Single Area Configuration
图2：单区域配置
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.
假设PE1在L1VPN1中连接到CE11和CE15，在L1VPN2中连接到CE22；PE2连接到L1VPN1中的CE13；PE3连接到L1VPN2中的CE24。在此配置中，PE1管理两个PIT：用于L1VPN1的PIT1和用于L1VPN2的PIT2；PE2只管理PIT1；PE3只管理PIT2。PE1发起三个L1VPN LSA，每个LSA分别包含一个L1VPN信息TLV广告链接PE1-CE11、PE1-CE22和PE1-CE15。PE2为链路PE2-CE13发起单个L1VPN LSA，PE3为链路PE3-CE24发起单个L1VPN LSA。在稳定状态下，PE1和PE3上的PIT1将包含关于链路PE1-CE11、PE1-CE15和PE2-CE13的信息；PE1和PE2上的PIT2将包含链接PE1-CE22和PE3-CE24的条目。因此，所有PEs将了解PEs支持的所有L1VPN的所有远程PE到CE链路。
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.
请注意，此配置中的P没有将其连接到任何L1VPN的链接。它既不启动LSA，也不维护任何凹坑。但是，它确实参与所有L1VPN LSA的泛洪，因此在其LSDB中维护LSA。这是可伸缩性问题的一个原因，在大型网络中可能会出现问题。
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
本文件中介绍的TLV和LSA均不存在任何互操作性问题。根据[RFC5250]，不支持L1VPN自动发现应用程序（例如Ps）的OSPF扬声器
participate in the L1VPN LSAs flooding process but should ignore the LSAs contents.
参与L1VPN LSA泛洪过程，但应忽略LSA内容。
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.
本文介绍的方法描述了PEs如何动态学习L1VPN特定信息。将VPN成员资格信息传递给CEs的机制明显超出了本文档的范围。因此，本文件中提出的安全问题仅限于OSPF域内。
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.
这种定义的方法重用了[RFC2328]和[RFC5250]中定义的机制。因此，相同的安全方法和注意事项适用于此方法。OSPF提供了几种可以应用的安全机制。具体来说，OSPF支持多种类型的身份验证，限制LSA发起和接受的频率，并提供避免和限制影响数据库溢出的技术。在需要端到端身份验证的情况下，OSPF的邻居到邻居身份验证方法可以通过对OSPF的实验性扩展进行扩充；请参阅[RFC2154]，它支持LSA的签名和身份验证。
This document requests the assignment of an OSPF Opaque LSA type. IANA has made the assignment in the form:
本文件要求分配OSPF不透明LSA类型。IANA已以以下形式进行了转让：
Value Opaque Type Reference
------- ----------- ---------
5 L1VPN LSA [RFC5252]
Value Opaque Type Reference
------- ----------- ---------
5 L1VPN LSA [RFC5252]
We would like to thank Adrian Farrel and Anton Smirnov for their useful comments.
我们要感谢阿德里安·法雷尔和安东·斯米尔诺夫的有益评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4203]Kompella，K.，Ed.，和Y.Rekhter，Ed.，“支持通用多协议标签交换（GMPLS）的OSPF扩展”，RFC 4203，2005年10月。
[RFC5250] Berger, L., Bryskin, I., and A. Zinin, "The OSPF Opaque LSA Option", RFC 5250, July 2008.
[RFC5250]Berger，L.，Bryskin，I.，和A.Zinin，“OSPF不透明LSA选项”，RFC 5250，2008年7月。
[RFC5251] Fedyk, D., Ed., Rekhter, Y., Ed., Papadimitriou, D., Rabbat, R., and L. Berger, "Layer 1 VPN Basic Mode", RFC 5251, July 2008.
[RFC5251]Fedyk，D.，Ed.，Rekhter，Y.，Ed.，Papadimitriou，D.，Rabbat，R.，和L.Berger，“第1层VPN基本模式”，RFC 52512008年7月。
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997.
[RFC2154]Murphy，S.，Badger，M.，和B.Wellington，“具有数字签名的OSPF”，RFC 2154，1997年6月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007.
[RFC4847]武田，T.，编辑，“第1层虚拟专用网络的框架和要求”，RFC 4847，2007年4月。
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[RFC5195]Ould Brahim，H.，Fedyk，D.，和Y.Rekhter，“基于BGP的第一层VPN自动发现”，RFC 51952008年6月。
Authors' Addresses
作者地址
Igor Bryskin ADVA Optical Networking Inc 7926 Jones Branch Drive Suite 615 McLean, VA 22102 EMail: ibryskin@advaoptical.com
Igor Bryskin ADVA光纤网络公司7926 Jones Branch Drive Suite 615 McLean，弗吉尼亚州22102电子邮件：ibryskin@advaoptical.com
Lou Berger LabN Consulting, LLC EMail: lberger@labn.net
Lou Berger LabN Consulting，LLC电子邮件：lberger@labn.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.