RFC5251 日本語訳
5251 Layer 1 VPN Basic Mode. D. Fedyk, Ed., Y. Rekhter, Ed., D.Papadimitriou, R. Rabbat, L. Berger. July 2008. (Format: TXT=57599 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Fedyk, Ed.
Request for Comments: 5251 Nortel
Category: Standards Track Y. Rekhter, Ed.
Juniper Networks
D. Papadimitriou
Alcatel-Lucent
R. Rabbat
Google
L. Berger
LabN
July 2008
Network Working Group D. Fedyk, Ed. Request for Comments: 5251 Nortel Category: Standards Track Y. Rekhter, Ed. Juniper Networks D. Papadimitriou Alcatel-Lucent R. Rabbat Google L. Berger LabN July 2008
Layer 1 VPN Basic Mode
Layer 1 VPN Basic Mode
Status of This Memo
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.
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
Abstract
This document describes the Basic Mode of Layer 1 VPNs (L1VPNs). L1VPN Basic Mode (L1VPN BM) is a port-based VPN. In L1VPN Basic Mode, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port topology. This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM.
This document describes the Basic Mode of Layer 1 VPNs (L1VPNs). L1VPN Basic Mode (L1VPN BM) is a port-based VPN. In L1VPN Basic Mode, the basic unit of service is a Label Switched Path (LSP) between a pair of customer ports within a given VPN port topology. This document defines the operational model using either provisioning or a VPN auto-discovery mechanism, and the signaling extensions for the L1VPN BM.
Fedyk, et al. Standards Track [Page 1] RFC 5251 L1VPN Basic Mode July 2008
Fedyk, et al. Standards Track [Page 1] RFC 5251 L1VPN Basic Mode July 2008
Table of Contents
Table of Contents
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Layer 1 VPN Service .............................................4
3. Addressing, Ports, Links, and Control Channels ..................7
3.1. Service Provider Realm .....................................7
3.2. Layer 1 Ports and Index ....................................7
3.3. Port and Index Mapping .....................................8
4. Port-Based L1VPN Basic Mode ....................................10
4.1. L1VPN Port Information Tables .............................11
4.1.1. Local Auto-Discovery Information ...................12
4.1.2. PE Remote Auto-Discovery Information ...............12
4.2. CE-to-CE LSP Establishment ................................14
4.3. Signaling .................................................15
4.3.1. Signaling Procedures ...............................15
4.3.1.1. Shuffling Sessions ........................16
4.3.1.2. Stitched or Nested Sessions ...............17
4.3.1.3. Other Signaling ...........................18
4.4. Recovery Procedures .......................................19
5. Security Considerations ........................................20
6. References .....................................................21
6.1. Normative References ......................................21
6.2. Informative References ....................................22
7. Acknowledgments ................................................23
1. Introduction ....................................................3 1.1. Conventions Used in This Document ..........................4 2. Layer 1 VPN Service .............................................4 3. Addressing, Ports, Links, and Control Channels ..................7 3.1. Service Provider Realm .....................................7 3.2. Layer 1 Ports and Index ....................................7 3.3. Port and Index Mapping .....................................8 4. Port-Based L1VPN Basic Mode ....................................10 4.1. L1VPN Port Information Tables .............................11 4.1.1. Local Auto-Discovery Information ...................12 4.1.2. PE Remote Auto-Discovery Information ...............12 4.2. CE-to-CE LSP Establishment ................................14 4.3. Signaling .................................................15 4.3.1. Signaling Procedures ...............................15 4.3.1.1. Shuffling Sessions ........................16 4.3.1.2. Stitched or Nested Sessions ...............17 4.3.1.3. Other Signaling ...........................18 4.4. Recovery Procedures .......................................19 5. Security Considerations ........................................20 6. References .....................................................21 6.1. Normative References ......................................21 6.2. Informative References ....................................22 7. Acknowledgments ................................................23
Fedyk, et al. Standards Track [Page 2] RFC 5251 L1VPN Basic Mode July 2008
Fedyk, et al. Standards Track [Page 2] RFC 5251 L1VPN Basic Mode July 2008
1. Introduction
1. Introduction
This document describes the Basic Mode of Layer 1 VPNs (L1VPN BM) that is outlined in [RFC4847]. The applicability of Layer 1 VPNS is covered in [RFC5253]. In this document, we consider a layer 1 service provider network that consists of devices that support GMPLS (e.g., Lambda Switch Capable (LSC) devices, optical cross-connects, Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) cross-connects, etc.). We partition these devices into P (provider) and PE (provider edge) devices. In the context of this document we will refer to the former devices as just "P", and to the latter devices as just "PE". The Ps are connected only to the devices within the provider's network. The PEs are connected to the other devices within the network (either Ps or PEs), as well as to the devices outside of the service provider network. We'll refer to such other devices as Customer Edge (CE) devices. An example of a CE would be a GMPLS-enabled device that is either a router, an SDH cross-connect, or an Ethernet switch.
This document describes the Basic Mode of Layer 1 VPNs (L1VPN BM) that is outlined in [RFC4847]. The applicability of Layer 1 VPNS is covered in [RFC5253]. In this document, we consider a layer 1 service provider network that consists of devices that support GMPLS (e.g., Lambda Switch Capable (LSC) devices, optical cross-connects, Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) cross-connects, etc.). We partition these devices into P (provider) and PE (provider edge) devices. In the context of this document we will refer to the former devices as just "P", and to the latter devices as just "PE". The Ps are connected only to the devices within the provider's network. The PEs are connected to the other devices within the network (either Ps or PEs), as well as to the devices outside of the service provider network. We'll refer to such other devices as Customer Edge (CE) devices. An example of a CE would be a GMPLS-enabled device that is either a router, an SDH cross-connect, or an Ethernet switch.
[RFC4208] defines signaling from the CE to the PE. In [RFC4208], the term "Core Node (CN)" corresponds to P and PE nodes, and the term "Edge Node (EN)" corresponds to CE nodes. We additionally define an "edge Core Node" corresponding to a PE.
[RFC4208] defines signaling from the CE to the PE. In [RFC4208], the term "Core Node (CN)" corresponds to P and PE nodes, and the term "Edge Node (EN)" corresponds to CE nodes. We additionally define an "edge Core Node" corresponding to a PE.
Figure 1 illustrates the components in an L1VPN network.
Figure 1 illustrates the components in an L1VPN network.
+---+ +---+
| P |....| P |
+---+ +---+
/ \
+-----+ +-----+ +--+
+--+ | PE | | |----| |
|CE|----| | | | |CE|
+--+\ +-----+ | |----| |
\ | | PE | +--+
\ +-----+ | |
\| PE | | | +--+
| | | |----|CE|
+-----+ +-----+ +--+
\ /
+---+ +---+
| P |....| P |
+---+ +---+
+---+ +---+ | P |....| P | +---+ +---+ / \ +-----+ +-----+ +--+ +--+ | PE | | |----| | |CE|----| | | | |CE| +--+\ +-----+ | |----| | \ | | PE | +--+ \ +-----+ | | \| PE | | | +--+ | | | |----|CE| +-----+ +-----+ +--+ \ / +---+ +---+ | P |....| P | +---+ +---+
Figure 1: Generalized Layer 1 VPN Reference Model
Figure 1: Generalized Layer 1 VPN Reference Model
Fedyk, et al. Standards Track [Page 3] RFC 5251 L1VPN Basic Mode July 2008
Fedyk, et al. Standards Track [Page 3] RFC 5251 L1VPN Basic Mode July 2008
This document specifies how the L1VPN Basic Mode service can be realized using off-line provisioning or VPN auto-discovery, Generalized Multi-Protocol Label Switching (GMPLS) Signaling [RFC3471], [RFC3473], Routing [RFC4202], and LMP [RFC4204] mechanisms.
This document specifies how the L1VPN Basic Mode service can be realized using off-line provisioning or VPN auto-discovery, Generalized Multi-Protocol Label Switching (GMPLS) Signaling [RFC3471], [RFC3473], Routing [RFC4202], and LMP [RFC4204] mechanisms.
L1VPN auto-discovery has similar requirements [RFC4847] to L3VPN auto-discovery. As with L3VPNs, there are protocol choices to be made with auto-discovery. Section 4.1.1 deals with the information that needs to be discovered.
L1VPN auto-discovery has similar requirements [RFC4847] to L3VPN auto-discovery. As with L3VPNs, there are protocol choices to be made with auto-discovery. Section 4.1.1 deals with the information that needs to be discovered.
GMPLS routing and signaling are used without extensions within the service provider network to establish and maintain LSC or SONET/SDH (Time Division Multiplexing (TDM)) connections between service provider nodes. This follows the model in [RFC4208].
GMPLS routing and signaling are used without extensions within the service provider network to establish and maintain LSC or SONET/SDH (Time Division Multiplexing (TDM)) connections between service provider nodes. This follows the model in [RFC4208].
In L1VPN Basic Mode, the use of LMP facilitates the population of the Port Information Tables of the service provider. Indeed, LMP MAY be used as an option to automate local CE-to-PE link discovery. LMP also MAY augment routing (in enhanced mode) as well as failure handling capabilities.
In L1VPN Basic Mode, the use of LMP facilitates the population of the Port Information Tables of the service provider. Indeed, LMP MAY be used as an option to automate local CE-to-PE link discovery. LMP also MAY augment routing (in enhanced mode) as well as failure handling capabilities.
Consideration of inter-AS and inter-provider L1VPNs requires further analysis beyond the scope of this document.
Consideration of inter-AS and inter-provider L1VPNs requires further analysis beyond the scope of this document.
1.1. Conventions Used in This Document
1.1. 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].
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].
This document expects that the reader is familiar with the terminology defined and used in [RFC3945], [RFC3471], [RFC3473], [RFC3477], [RFC4201], [RFC4202], [RFC4204], [RFC4208], and the documents referenced therein.
This document expects that the reader is familiar with the terminology defined and used in [RFC3945], [RFC3471], [RFC3473], [RFC3477], [RFC4201], [RFC4202], [RFC4204], [RFC4208], and the documents referenced therein.
2. Layer 1 VPN Service
2. Layer 1 VPN Service
Layer 1 VPN services on the interfaces of customer and service provider ports MAY be any of the Layer 1 interfaces supported by GMPLS. Since the mechanisms specified in this document use GMPLS as the signaling mechanism, and since GMPLS applies to both SONET/SDH (TDM) and LSC interfaces, it follows that L1VPN services include (but are not restricted) to LSC- or TDM-based equipment. Note that this document describes Basic Mode L1VPNs and as such requires that:
Layer 1 VPN services on the interfaces of customer and service provider ports MAY be any of the Layer 1 interfaces supported by GMPLS. Since the mechanisms specified in this document use GMPLS as the signaling mechanism, and since GMPLS applies to both SONET/SDH (TDM) and LSC interfaces, it follows that L1VPN services include (but are not restricted) to LSC- or TDM-based equipment. Note that this document describes Basic Mode L1VPNs and as such requires that:
Fedyk, et al. Standards Track [Page 4] RFC 5251 L1VPN Basic Mode July 2008
Fedyk, et al. Standards Track [Page 4] RFC 5251 L1VPN Basic Mode July 2008
(1) GMPLS RSVP-TE is used for signaling both within the service
provider (between PEs), as well as between the customer and the
service provider (between CE and PE);
(1) GMPLS RSVP-TE is used for signaling both within the service provider (between PEs), as well as between the customer and the service provider (between CE and PE);
(2) GMPLS Routing on the CE-to-PE link is outside the scope of the
Basic Mode of operation of L1VPN; see [RFC4847].
(2) GMPLS Routing on the CE-to-PE link is outside the scope of the Basic Mode of operation of L1VPN; see [RFC4847].
A CE is connected to a PE via one or more links. In the context of this document, a link is a GMPLS Traffic Engineering (TE) link construct, as defined in [RFC4202]. In the context of this document, a TE link is a logical construct that is a member of a VPN, hence introducing the notion of membership to a set of CEs forming the VPN. Interfaces at the end of each link are limited to either TDM or LSC as supported by GMPLS. More specifically, a <CE, PE> link MUST be of the type <X, LSC> or <Y, TDM> where X = PSC (Packet Switch Capable), L2SC (Layer 2 Switch Capable), or TDM and Y = PSC or L2SC. In case the LSP is not terminated by the CE, X MAY also = LSC and Y = TDM. One of the applications of a L1VPN connection is to provide a "virtual private lambda" or similar. In this case, the CE is truly the endpoint in GMPLS terms, and its switching capability on the TE link is not relevant (although its Generalized Protocol Identifier (GPID) MUST be signaled and identical at both CEs, i.e., head-end and tail-end CE).
A CE is connected to a PE via one or more links. In the context of this document, a link is a GMPLS Traffic Engineering (TE) link construct, as defined in [RFC4202]. In the context of this document, a TE link is a logical construct that is a member of a VPN, hence introducing the notion of membership to a set of CEs forming the VPN. Interfaces at the end of each link are limited to either TDM or LSC as supported by GMPLS. More specifically, a <CE, PE> link MUST be of the type <X, LSC> or <Y, TDM> where X = PSC (Packet Switch Capable), L2SC (Layer 2 Switch Capable), or TDM and Y = PSC or L2SC. In case the LSP is not terminated by the CE, X MAY also = LSC and Y = TDM. One of the applications of a L1VPN connection is to provide a "virtual private lambda" or similar. In this case, the CE is truly the endpoint in GMPLS terms, and its switching capability on the TE link is not relevant (although its Generalized Protocol Identifier (GPID) MUST be signaled and identical at both CEs, i.e., head-end and tail-end CE).
Likewise, PEs could be any Layer 1 devices that are supported by GMPLS (e.g., optical cross-connects, SDH cross-connects), while CEs MAY be devices at layers 1, 2, and 3, such as an SDH cross-connect, an Ethernet switch, and a router, respectively).
Likewise, PEs could be any Layer 1 devices that are supported by GMPLS (e.g., optical cross-connects, SDH cross-connects), while CEs MAY be devices at layers 1, 2, and 3, such as an SDH cross-connect, an Ethernet switch, and a router, respectively).
Each TE link MAY consist of one or more channels or sub-channels (e.g., wavelength or wavelength and timeslot, respectively). For the purpose of this discussion, all the channels within a given link MUST have similar shared characteristics (e.g., switching capability, encoding, type, etc.), and MAY be selected independently from the CE's point of view. Channels on different links of a CE need not have the same characteristics.
Each TE link MAY consist of one or more channels or sub-channels (e.g., wavelength or wavelength and timeslot, respectively). For the purpose of this discussion, all the channels within a given link MUST have similar shared characteristics (e.g., switching capability, encoding, type, etc.), and MAY be selected independently from the CE's point of view. Channels on different links of a CE need not have the same characteristics.
There MAY be more than one TE link between a given CE-PE pair. A CE MAY be connected to more than one PE (with at least one port per PE). And, conversely, a PE MAY have more than one CE from different VPNs connected to it.
There MAY be more than one TE link between a given CE-PE pair. A CE MAY be connected to more than one PE (with at least one port per PE). And, conversely, a PE MAY have more than one CE from different VPNs connected to it.
If a CE is connected to a PE via multiple TE links and all the links belong to the same VPN, these links (referred to as component links) MAY be treated as a single TE link using the link bundling constructs [RFC4201].
If a CE is connected to a PE via multiple TE links and all the links belong to the same VPN, these links (referred to as component links) MAY be treated as a single TE link using the link bundling constructs [RFC4201].
Fedyk, et al. Standards Track [Page 5] RFC 5251 L1VPN Basic Mode July 2008
Fedyk, et al. Standards Track [Page 5] RFC 5251 L1VPN Basic Mode July 2008
In order to satisfy the requirements of the L1VPN Basic Mode, it is REQUIRED that for a given CE-PE pair at least one of the links between them has at least one data bearing channel, and at least one control bearing channel, or that there is IP reachability between the CE and the PE that could be used to exchange control information.
In order to satisfy the requirements of the L1VPN Basic Mode, it is REQUIRED that for a given CE-PE pair at least one of the links between them has at least one data bearing channel, and at least one control bearing channel, or that there is IP reachability between the CE and the PE that could be used to exchange control information.
A point-to-point link has two end-points: one on the CE and one on the PE. This document refers to the former as "CE port", and to the latter as "PE port". From the above, it follows that a CE is connected to a PE via one or more ports, where each port MAY consist of one or more channels or sub-channels (e.g., wavelength or wavelength and timeslot, respectively), and all the channels within a given port have shared similar characteristics and can be interchanged from the CE's point of view. Similar to the definition of a TE link, in the context of this document, ports are logical constructs that are used to represent a grouping of physical resources that are used to connect a CE to a PE on a per-L1VPN basis.
A point-to-point link has two end-points: one on the CE and one on the PE. This document refers to the former as "CE port", and to the latter as "PE port". From the above, it follows that a CE is connected to a PE via one or more ports, where each port MAY consist of one or more channels or sub-channels (e.g., wavelength or wavelength and timeslot, respectively), and all the channels within a given port have shared similar characteristics and can be interchanged from the CE's point of view. Similar to the definition of a TE link, in the context of this document, ports are logical constructs that are used to represent a grouping of physical resources that are used to connect a CE to a PE on a per-L1VPN basis.
At any point in time, a given port on a PE is associated with at most one L1VPN, or, to be more precise, with at most one Port Information Table maintained by the PE (although different ports on a given PE could be associated with different L1VPNs, or, to be more precise, with different Port Information Tables). The association of a port with a VPN MAY be defined by provisioning the relationship on the service provider devices. In other words, the context of a VPN membership in Basic Mode is enforced through service provider control.
At any point in time, a given port on a PE is associated with at most one L1VPN, or, to be more precise, with at most one Port Information Table maintained by the PE (although different ports on a given PE could be associated with different L1VPNs, or, to be more precise, with different Port Information Tables). The association of a port with a VPN MAY be defined by provisioning the relationship on the service provider devices. In other words, the context of a VPN membership in Basic Mode is enforced through service provider control.
It is REQUIRED that the interface (that is between the CE and PE and that is used for the purpose of signaling) be capable of initiating/processing GMPLS protocol messages [RFC3473] and of following the procedures described in [RFC4208].
It is REQUIRED that the interface (that is between the CE and PE and that is used for the purpose of signaling) be capable of initiating/processing GMPLS protocol messages [RFC3473] and of following the procedures described in [RFC4208].
An important goal of L1VPN service is the ability to support what is known as "single-ended provisioning", where the addition of a new port to a given L1VPN involves configuration changes only on the PE that has this port. The extension of this model to the CE is outside the scope of the L1VPN BM.
An important goal of L1VPN service is the ability to support what is known as "single-ended provisioning", where the addition of a new port to a given L1VPN involves configuration changes only on the PE that has this port. The extension of this model to the CE is outside the scope of the L1VPN BM.
Another important goal in the L1VPN service is the ability to establish/terminate an LSP between a pair of (existing) ports within an L1VPN from the CE devices without involving configuration changes in any of the service provider's devices. In other words, the VPN topology is under the CE device control (assuming that the underlying PE-to-PE connectivity is provided and allowed by the network).
Another important goal in the L1VPN service is the ability to establish/terminate an LSP between a pair of (existing) ports within an L1VPN from the CE devices without involving configuration changes in any of the service provider's devices. In other words, the VPN topology is under the CE device control (assuming that the underlying PE-to-PE connectivity is provided and allowed by the network).
Fedyk, et al. Standards Track [Page 6] RFC 5251 L1VPN Basic Mode July 2008
Fedyk, et al. Standards Track [Page 6] RFC 5251 L1VPN Basic Mode July 2008
The mechanisms outlined in this document aim to achieve the above goals. Specifically, as part of the L1VPN service offering, these mechanisms (1) enable the service provider to restrict the set of ports to which a given port could be connected and (2) enable a CE to establish the actual LSP to a subset of ports. Finally, the mechanisms allow arbitrary L1VPN topologies to be supported; including topologies ranging from hub-and-spoke to full mesh point- to-point connections. Only point-to-point links are supported.
The mechanisms outlined in this document aim to achieve the above goals. Specifically, as part of the L1VPN service offering, these mechanisms (1) enable the service provider to restrict the set of ports to which a given port could be connected and (2) enable a CE to establish the actual LSP to a subset of ports. Finally, the mechanisms allow arbitrary L1VPN topologies to be supported; including topologies ranging from hub-and-spoke to full mesh point- to-point connections. Only point-to-point links are supported.
The exchange of CE routing or topology information to the service provider is out of scope for L1VPN BM mode.
The exchange of CE routing or topology information to the service provider is out of scope for L1VPN BM mode.
3. Addressing, Ports, Links, and Control Channels
3. Addressing, Ports, Links, and Control Channels
GMPLS-established conventions for addressing and link numbering are discussed in [RFC3945]. This section builds on those definitions for the L1VPN case where we now have customer and service provider addresses in a Layer 1 context.
GMPLS-established conventions for addressing and link numbering are discussed in [RFC3945]. This section builds on those definitions for the L1VPN case where we now have customer and service provider addresses in a Layer 1 context.
3.1. Service Provider Realm
3.1. Service Provider Realm
It is REQUIRED that a service provider, or a group of service providers that collectively offer L1VPN service, have a single addressing realm that spans all PE devices involved in providing the L1VPN service. This is necessary to enable GMPLS mechanisms for path establishment and maintenance. We will refer to this realm as the service provider addressing realm. It is further REQUIRED that each L1VPN customer have its own addressing realm with complete freedom to use private or public addresses. We will refer to such realms as the customer addressing realms. Customer addressing realms MAY overlap addresses (i.e., non-unique address) with each other, and MAY also overlap addresses with the service provider realm.
It is REQUIRED that a service provider, or a group of service providers that collectively offer L1VPN service, have a single addressing realm that spans all PE devices involved in providing the L1VPN service. This is necessary to enable GMPLS mechanisms for path establishment and maintenance. We will refer to this realm as the service provider addressing realm. It is further REQUIRED that each L1VPN customer have its own addressing realm with complete freedom to use private or public addresses. We will refer to such realms as the customer addressing realms. Customer addressing realms MAY overlap addresses (i.e., non-unique address) with each other, and MAY also overlap addresses with the service provider realm.
3.2. Layer 1 Ports and Index
3.2. Layer 1 Ports and Index
Within a given L1VPN, each port on a CE that connects the CE to a PE has an identifier that is unique within that L1VPN (but need not be unique across several L1VPNs). One way to construct such an identifier is to assign each port an address that is unique within a given L1VPN, and use this address as a port identifier. Another way to construct such an identifier is to assign each port on a CE an index that is unique within that CE, assign each CE an address that is unique within a given L1VPN, and then use a tuple <port index, CE address> as a port identifier. Note that both the port and the CE address MAY be an address in several formats. This includes, but is not limited to, IPv4 and IPv6. This identifier is part of the
Within a given L1VPN, each port on a CE that connects the CE to a PE has an identifier that is unique within that L1VPN (but need not be unique across several L1VPNs). One way to construct such an identifier is to assign each port an address that is unique within a given L1VPN, and use this address as a port identifier. Another way to construct such an identifier is to assign each port on a CE an index that is unique within that CE, assign each CE an address that is unique within a given L1VPN, and then use a tuple <port index, CE address> as a port identifier. Note that both the port and the CE address MAY be an address in several formats. This includes, but is not limited to, IPv4 and IPv6. This identifier is part of the
Fedyk, et al. Standards Track [Page 7] RFC 5251 L1VPN Basic Mode July 2008
Fedyk, et al. Standards Track [Page 7] RFC 5251 L1VPN Basic Mode July 2008
Customer addressing Realm and is used by the CE device to identify the CE port and the CE remote port for signaling. CEs do not know or understand the service provider realm addresses.
Customer addressing Realm and is used by the CE device to identify the CE port and the CE remote port for signaling. CEs do not know or understand the service provider realm addresses.
Within a service provider network, each port on a PE that connects that PE to a CE has an identifier that is unique within that network. One way to construct such an identifier is to assign each port on a PE an index that is unique within that PE, assign each PE an IP address that is unique within the service provider addressing realm, and then use a tuple <port index, PE IPv4 address> or <port index, PE IPv6 address> as a port identifier within the service provider network. Another way to construct such an identifier is to assign an IPv4 or IPv6 address that is unique within the service provider addressing realm to each such port. Either way, this IPv4 or IPv6 address is internal to the service provider network and is used for GMPLS signaling within the service provider network.
Within a service provider network, each port on a PE that connects that PE to a CE has an identifier that is unique within that network. One way to construct such an identifier is to assign each port on a PE an index that is unique within that PE, assign each PE an IP address that is unique within the service provider addressing realm, and then use a tuple <port index, PE IPv4 address> or <port index, PE IPv6 address> as a port identifier within the service provider network. Another way to construct such an identifier is to assign an IPv4 or IPv6 address that is unique within the service provider addressing realm to each such port. Either way, this IPv4 or IPv6 address is internal to the service provider network and is used for GMPLS signaling within the service provider network.
As a result, each link connecting the CE to the PE is associated with a CE port that has a unique identifier within a given L1VPN, and with a PE port that has a unique identifier within the service provider network. We'll refer to the former as the Customer Port Identifier (CPI), and to the latter as the Provider Port Identifier (PPI).
As a result, each link connecting the CE to the PE is associated with a CE port that has a unique identifier within a given L1VPN, and with a PE port that has a unique identifier within the service provider network. We'll refer to the former as the Customer Port Identifier (CPI), and to the latter as the Provider Port Identifier (PPI).
3.3. Port and Index Mapping
3.3. Port and Index Mapping
This document requires that each PE port that has a PPI also has an identifier that is unique within the L1VPN customer addressing realm of the L1VPN associated with that port. One way to construct such an identifier is to assign each port an address that is unique within a given L1VPN customer addressing realm, and use this address as a port identifier. Another way to construct such an identifier is to assign each port an index that is unique within a given PE, assign each PE an IP address that is unique within a given L1VPN customer addressing realm (but need not be unique within the service provider network), and then use a tuple <port index, PE IP address> that acts as a port identifier. We'll refer to such port identifier as the VPN-PPI. See Figure 2.
This document requires that each PE port that has a PPI also has an identifier that is unique within the L1VPN customer addressing realm of the L1VPN associated with that port. One way to construct such an identifier is to assign each port an address that is unique within a given L1VPN customer addressing realm, and use this address as a port identifier. Another way to construct such an identifier is to assign each port an index that is unique within a given PE, assign each PE an IP address that is unique within a given L1VPN customer addressing realm (but need not be unique within the service provider network), and then use a tuple <port index, PE IP address> that acts as a port identifier. We'll refer to such port identifier as the VPN-PPI. See Figure 2.
For L1VPNs, it is a requirement that service provider operations are independent of the VPN customer's addressing realm and the service provider addressing realm is hidden from the customer. To achieve this, we define two identifiers at the PE, one customer facing and the other service provider facing. The PE IP address used for the VPN-PPI is independent of the PE IP address used for the PPI (as the two are taken from different address realms, the former from the customer's addressing realm and the latter from a VPN service provider's addressing realm). If for a given port on a PE, the PPI
For L1VPNs, it is a requirement that service provider operations are independent of the VPN customer's addressing realm and the service provider addressing realm is hidden from the customer. To achieve this, we define two identifiers at the PE, one customer facing and the other service provider facing. The PE IP address used for the VPN-PPI is independent of the PE IP address used for the PPI (as the two are taken from different address realms, the former from the customer's addressing realm and the latter from a VPN service provider's addressing realm). If for a given port on a PE, the PPI
Fedyk, et al. Standards Track [Page 8] RFC 5251 L1VPN Basic Mode July 2008
Fedyk, et al. Standards Track [Page 8] RFC 5251 L1VPN Basic Mode July 2008
and the VPN-PPI port identifiers are unnumbered, then they both could use exactly the same port index. This is a mere convenience since the PPI and VPN_PPI can be in any combination of valid formats.
and the VPN-PPI port identifiers are unnumbered, then they both could use exactly the same port index. This is a mere convenience since the PPI and VPN_PPI can be in any combination of valid formats.
(Customer realm)
+----+ +----+
| |<Port Index> <Port Index> | |
| |CPI VPN-PPI | |
---| CE |-----------------------------| PE |---
| | <Port Index> | |
| | PPI | |
+----+ +----+
(Provider realm)
(Customer realm) +----+ +----+ | |<Port Index> <Port Index> | | | |CPI VPN-PPI | | ---| CE |-----------------------------| PE |--- | | <Port Index> | | | | PPI | | +----+ +----+ (Provider realm)
Figure 2: Customer/Provider Port/Index Mapping
Figure 2: Customer/Provider Port/Index Mapping
Note, as stated earlier, that IP addresses used for the CPIs, PPIs, and VPN-PPIs could be either IPv4 or IPv6 format addresses.
Note, as stated earlier, that IP addresses used for the CPIs, PPIs, and VPN-PPIs could be either IPv4 or IPv6 format addresses.
For a given link connecting a CE to a PE:
For a given link connecting a CE to a PE:
- If the CPI is an IPv4 address, then the VPN-PPI MUST be an IPv4
address as well since VPN-PPIs are created from the customer
address space. If the CPI is a <port index, CPI IPv4 address>
tuple, then the VPN-PPI MUST be a <port index, PE IPv4 address>
tuple for the same reason.
- If the CPI is an IPv4 address, then the VPN-PPI MUST be an IPv4 address as well since VPN-PPIs are created from the customer address space. If the CPI is a <port index, CPI IPv4 address> tuple, then the VPN-PPI MUST be a <port index, PE IPv4 address> tuple for the same reason.
- If the CPI is an IPv6 address, then the VPN-PPI MUST be an IPv6
address as well since VPN-PPIs are created from the customer
address space. If the CPI is a <port index, CPI IPv6 address>
tuple, then the VPN-PPI MUST be a <port index, PE IPv6 address>
tuple for the same reason.
- If the CPI is an IPv6 address, then the VPN-PPI MUST be an IPv6 address as well since VPN-PPIs are created from the customer address space. If the CPI is a <port index, CPI IPv6 address> tuple, then the VPN-PPI MUST be a <port index, PE IPv6 address> tuple for the same reason.
Note: for a given port on the PE, whether the VPN-PPI of that port is an IP address or a <port index, PE IP address> is independent of the format of the PPI of that port.
Note: for a given port on the PE, whether the VPN-PPI of that port is an IP address or a <port index, PE IP address> is independent of the format of the PPI of that port.
This document assumes that assignment of the PPIs is controlled solely by the service provider (without any coordination with the L1VPN customers), while assignment of addresses used by the CPIs and VPN-PPIs is controlled solely by the administrators of L1VPN. This provides maximum flexibility. The L1VPN administrator is the entity that controls the L1VPN service specifics for the L1VPN customers. This function may be owned by the service provider but may also be performed by a third party who has agreements with the service provider. And, of course, each L1VPN customer could assign such addresses on its own, without any coordination with other L1VPNs.
This document assumes that assignment of the PPIs is controlled solely by the service provider (without any coordination with the L1VPN customers), while assignment of addresses used by the CPIs and VPN-PPIs is controlled solely by the administrators of L1VPN. This provides maximum flexibility. The L1VPN administrator is the entity that controls the L1VPN service specifics for the L1VPN customers. This function may be owned by the service provider but may also be performed by a third party who has agreements with the service provider. And, of course, each L1VPN customer could assign such addresses on its own, without any coordination with other L1VPNs.
Fedyk, et al. Standards Track [Page 9] RFC 5251 L1VPN Basic Mode July 2008
Fedyk, et al. Standards Track [Page 9] RFC 5251 L1VPN Basic Mode July 2008
This document also requires IP connectivity between the CE and the PE as specified earlier, which is used for the control channel between CE and PE. This connectivity could be either a single IP hop, which could be realized by either a dedicated link or by an L2 VPN, or an IP private network, such as an L3VPN. The only requirement on this connectivity is an unambiguous way to correlate a particular CE-to-PE control channel with a particular L1VPN. When such a channel is realized by a dedicated link, such a link should be associated with a particular L1VPN. When such channel is realized by an L2VPN, a distinct L2VPN should be associated with an L1VPN. When such channel is realized by an L3VPN, a distinct L3VPN should be associated with an L1VPN.
This document also requires IP connectivity between the CE and the PE as specified earlier, which is used for the control channel between CE and PE. This connectivity could be either a single IP hop, which could be realized by either a dedicated link or by an L2 VPN, or an IP private network, such as an L3VPN. The only requirement on this connectivity is an unambiguous way to correlate a particular CE-to-PE control channel with a particular L1VPN. When such a channel is realized by a dedicated link, such a link should be associated with a particular L1VPN. When such channel is realized by an L2VPN, a distinct L2VPN should be associated with an L1VPN. When such channel is realized by an L3VPN, a distinct L3VPN should be associated with an L1VPN.
We'll refer to the CE's address of this channel as the CE Control Channel Address (CE-CC-Addr), and to the PE's address of this channel as the PE Control Channel Address (PE-CC-Addr). Both CE-CC-Addr and PE-CC-Addr are REQUIRED to be unique within the L1VPN they belong to, but are not REQUIRED to be unique across multiple L1VPNs. Control channel addresses are not shared amongst multiple VPNs. Assignment of CE-CC-Addr and PE-CC-Addr is controlled by the administrators of the L1VPN.
We'll refer to the CE's address of this channel as the CE Control Channel Address (CE-CC-Addr), and to the PE's address of this channel as the PE Control Channel Address (PE-CC-Addr). Both CE-CC-Addr and PE-CC-Addr are REQUIRED to be unique within the L1VPN they belong to, but are not REQUIRED to be unique across multiple L1VPNs. Control channel addresses are not shared amongst multiple VPNs. Assignment of CE-CC-Addr and PE-CC-Addr is controlled by the administrators of the L1VPN.
Multiple ports on a CE could share the same control channel only as long as all these ports belong to the same L1VPN. Likewise, multiple ports on a PE could share the same control channel only as long as all these ports belong to the same L1VPN.
Multiple ports on a CE could share the same control channel only as long as all these ports belong to the same L1VPN. Likewise, multiple ports on a PE could share the same control channel only as long as all these ports belong to the same L1VPN.
4. Port-Based L1VPN Basic Mode
4. Port-Based L1VPN Basic Mode
An L1VPN is a port-based VPN service where a pair of CEs could be connected through the service provider network via a GMPLS-based LSP within a given VPN port topology. It is precisely this LSP that forms the basic unit of the L1VPN service that the service provider network offers. If a port by which a CE is connected to a PE consists of multiple channels (e.g., multiple wavelengths), the CE could establish LSPs to multiple other CEs in the same VPN over this single port.
An L1VPN is a port-based VPN service where a pair of CEs could be connected through the service provider network via a GMPLS-based LSP within a given VPN port topology. It is precisely this LSP that forms the basic unit of the L1VPN service that the service provider network offers. If a port by which a CE is connected to a PE consists of multiple channels (e.g., multiple wavelengths), the CE could establish LSPs to multiple other CEs in the same VPN over this single port.
In the L1VPN, the service provider does not initiate the creation of an LSP between a pair of CE ports. The LSP establishment is initiated by the CE. However, the SP, by using the mechanisms/toolkit outlined in this document, restricts the set of other CE ports, which may be the remote endpoints of LSPs that have the given port as the local endpoint. Subject to these restrictions, the CE-to-CE connectivity is under the control of the CEs themselves. In other words, the SP allows a L1VPN to have a certain set of
L1VPNでは、サービスプロバイダーは1組のCEポートの間のLSPの創造を開始しません。 LSP設立はCEによって開始されます。 しかしながら、本書では概説されたメカニズム/ツールキットを使用することによって、SPは他のCEポートのセットを制限します。(ポートは地方の終点として与えられたポートを持っているLSPsの遠く離れた終点であるかもしれません)。 これらの制限を条件として、CEからCEへの接続性がCEs自身のコントロールの下にあります。 言い換えれば、SPはL1VPNにaを確かに設定していた状態でさせます。
Fedyk, et al. Standards Track [Page 10] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[10ページ]RFC5251L1VPN
topologies (expressed as a port-to-port connectivity matrix). CE-initiated signaling is used to choose a particular topology from that set.
topologies(移植するポート接続性マトリクスとして、言い表されます)。 CEによって開始されたシグナリングは、そのセットから特定のトポロジーを選ぶのに使用されます。
For each L1VPN that has at least one port on a given PE, the PE maintains a Port Information Table (PIT) associated with that L1VPN. This table contains a list of <CPI, PPI> tuples for all the ports within its L1VPN. In addition, for local PE ports of a given L1VPN, the tuples also include the VPN-PPIs of these ports.
与えられたPEに少なくとも1つのポートを持っている各L1VPNに関しては、PEはPort情報Table(PIT)をそのL1VPNに関連しているのに維持します。 このテーブルはL1VPNの中に<CPIのリスト、すべてのポートへのPPI>tuplesを含んでいます。 また、さらに、与えられたL1VPNの地方のPEポートに関して、tuplesはこれらのポートのVPN-PPIsを含んでいます。
PE PE
+---------+ +--------------+
+--------+ | +------+| | +----------+ | +--------+
| VPN-A | | |VPN-A || | | VPN-A | | | VPN-A |
| CE1 |--| |PIT || Route | | PIT | |-| CE2 |
+--------+ | | ||<----------->| | | | +--------+
| +------+|Dissemination| +----------+ |
| | | |
+--------+ | +------+| | +----------+ | +--------+
| 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|--| |穴|| ルート| | 穴| |-| CE2| +--------+ | | | | <、-、-、-、-、-、-、-、-、-、--、>|、|、|、| +--------+ | +------+|普及| +----------+ | | | | | +--------+ | +------+| | +----------+ | +--------+ | VPN-B| | |VPN-B|| -------- | | VPN-B| | | VPN-B| | CE1|--| |穴||-(GMPLS)-| | 穴| |-| CE2| +--------+ | | || (背骨) | | | | +--------+ | +------+| --------- | +----------+ | | | | | +--------+ | +-----+ | | +----------+ | +--------+ | VPN-C| | |VPN-C| | | | VPN-C| | | VPN-C| | CE1|--| |穴| | | | 穴| |-| CE2| +--------+ | | | | | | | | +--------+ | +-----+ | | +----------+ | +---------+ +--------------+
Figure 3: Basic Mode L1VPN Service
図3: 基本的なモードL1VPNサービス
4.1. L1VPN Port Information Tables
4.1. L1VPNポート情報テーブル
Figure 3 illustrates three VPNs, VPN-A, VPN-B, and VPN-C, with their associated PITs. A PIT consists of local information as well as remote information. It follows that a PIT on a given PE is populated from two information sources:
図3は彼らの関連PITsと共に3VPNs、VPN-A、VPN-B、およびVPN-Cを例証します。 PITはリモート情報と同様にローカルの情報から成ります。 与えられたPEの上のPITが2つの情報源から居住されるということになります:
1. The information related to the CEs' ports that are attached to
the ports local to that PE.
1. 情報はそのPEへの地方のポートに取り付けられるCEsのポートに関連しました。
2. The information about the CEs connected to the remote PEs.
2. CEsの情報はリモートPEsに接続しました。
Fedyk, et al. Standards Track [Page 11] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[11ページ]RFC5251L1VPN
A PIT MAY be populated via provisioning or by auto-discovery procedures. When provisioning is used, the entire table MAY be populated by provisioning commands either at a console or by a management system that may have some automation capability. As the network grows, some form of automation is desirable.
PIT MAY、食糧を供給することを通して自動発見手順で、居住されてください。 食糧を供給するのが使用されているとき、コンソールにおいて、または、何らかのオートメーション能力を持っているかもしれないマネージメントシステムでコマンドに食糧を供給することによって、全体のテーブルは居住されるかもしれません。 ネットワークが成長するので、何らかのフォームのオートメーションは望ましいです。
For local information between a CE and a PE, a PE MAY leverage LMP to populate the <CPI, VPN-PPI> link information. This local information also needs to be propagated to other PEs that share the same VPN. The mechanisms for this are out of scope for this document, but the information needed to be exchanged is described in Section 4.1.1.
CEとPE、PE MAYの間のローカルの情報に関しては、LMPに投機して、<CPI(VPN-PPI>リンク情報)に居住してください。 また、このローカルの情報は、同じVPNを共有する他のPEsに伝播される必要があります。 このドキュメントのための範囲の外にこれのためのメカニズムがありますが、交換するのに必要である情報はセクション4.1.1で説明されます。
The PIT is by nature VPN-specific. A PE is REQUIRED to maintain a PIT for each L1VPN for which it has member CEs locally attached. A PE does not need to maintain PITs for other L1VPNs. However, the full set of PITs with all L1VPN entries for multiple VPNs MAY also be available to all PEs.
自然で、PITはVPN特有です。 PEはそれが局所的にメンバーCEsを持っているそれぞれの添付のL1VPNのためにPITを維持するREQUIREDです。 PEは他のL1VPNsのためにPITsを維持する必要はありません。 しかしながら、また、複数のVPNsのためのすべてのL1VPNエントリーによるPITsのフルセットもすべてのPEsに利用可能であるかもしれません。
The remote information in the context of a VPN identifier (i.e., the remote CEs of this VPN) MAY also be sent to the local CE belonging to the same VPN. Exchange of this information is outside the scope of this document.
また、VPN識別子(すなわち、このVPNのリモートCEs)の文脈のリモート情報を同じVPNに属す地方のCEに送るかもしれません。 このドキュメントの範囲の外にこの情報の交換があります。
4.1.1. Local Auto-Discovery Information
4.1.1. ローカルの自動発見情報
The information that needs to be discovered on a PE local port is the local CPI and the VPN-PPI.
PEの地方のポートの上で発見される必要がある情報は、ローカルのCPIとVPN-PPIです。
This information MAY be configured; or, if LMP is used between the CE and PE, LMP MAY be used to exchange this information.
この情報は構成されるかもしれません。 または、LMPが使用されているならCEとPE、LMP MAYの間では、使用されて、この情報を交換してください。
Once a CPI has been discovered, the corresponding VPN-PPI maps in a local context to a VPN identifier and a corresponding PPI. One way to enforce a provider-controlled VPN context is to pre-provision VPN-PPIs with a VPN identifier. Other policy mechanisms to achieve this are outside the scope of this document. In this manner, a relationship of a CPI to a VPN and PPI port can be established when the port is provisioned as belonging to the VPN.
かつて、CPIを発見してあって、対応するVPN-PPIはVPN識別子と対応するPPIへのローカルの関係の地図です。 VPN識別子があるプレ支給VPN-PPIsにはプロバイダーで制御されたVPN文脈を実施する1つの方法があります。 このドキュメントの範囲の外にこれを達成する他の方針メカニズムがあります。 ポートがVPNに属すとして食糧を供給されるとき、この様に、VPNとPPIポートへのCPIの関係を確立できます。
4.1.2. PE Remote Auto-Discovery Information
4.1.2. PEのリモート自動発見情報
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- discovery mechanism will define the method(s) by which multiple <CPI, PPI> mappings are communicated, as well as invalidated.
このセクションはどんな自動発見メカニズムによっても運ばれて、ダイナミックにPITに居住するのに使用される情報を提供します。 情報はただ一つの<CPI、PPI>マッピングを提供します。 それぞれの自動発見メカニズムがどの複数の<CPIで方法を定義するだろうか、そして、PPI>マッピングは、伝えられて、無効にされます。
Fedyk, et al. Standards Track [Page 12] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[12ページ]RFC5251L1VPN
This information should be consistent regardless of the mechanism used to distribute the information [RFC5195], [RFC5252].
[RFC5252]、この情報は情報を分配するのに使用されるメカニズム[RFC5195]にかかわらず一貫しているべきです。
The format of encoding a single <PPI, CPI> tuple is:
独身の<PPIをコード化する形式であり、CPI>tupleは以下の通りです。
+---------------------------------------+
| PPI Length (1 octet) |
+---------------------------------------+
| PPI (variable) |
+---------------------------------------+
| CPI AFI (2 octets) |
+---------------------------------------+
| CPI (length) |
+---------------------------------------+
| CPI (variable) |
+---------------------------------------+
+---------------------------------------+ | PPI Length(1つの八重奏)| +---------------------------------------+ | PPI(可変)| +---------------------------------------+ | CPI AFI(2つの八重奏)| +---------------------------------------+ | CPI(長さ)| +---------------------------------------+ | CPI(変数)| +---------------------------------------+
Figure 4: Auto-Discovery Information
図4: 自動発見情報
The use and meaning of these fields are as follows:
これらの分野の使用と意味は以下の通りです:
PPI Length:
PPIの長さ:
A one-octet field whose value indicates the length of the PPI
field.
値がPPI分野の長さを示す1八重奏の分野。
PPI:
PPI:
A variable-length field that contains the value of the PPI (either
an address or <port index, address> tuple). Note, PPI is always
encoded consistently within a provider domain so the format of the
PPI field is implicit within a given provider network.
PPI(アドレスか<ポートインデックス、アドレス>tupleのどちらか)の値を含む可変長の分野。 注意、PPIがプロバイダードメインの中でいつも一貫してコード化されるので、PPI分野の形式は与えられたプロバイダーネットワークの中で暗に示されています。
CPI AFI:
CPI AFI:
A two-octet field whose value indicates the address family of the
CPI. This value is taken from [RFC1700].
値がCPIのアドレス家族を示す2八重奏の分野。 [RFC1700]からこの値を取ります。
CPI Length:
CPIの長さ:
A one-octet field whose value indicates the length of the CPI
field.
値がCPI分野の長さを示す1八重奏の分野。
CPI:
CPI:
A variable-length field that contains the CPI value (either an
address or <port index, address> tuple).
CPI値(アドレスか<ポートインデックス、アドレス>tupleのどちらか)を含む可変長の分野。
Fedyk, et al. Standards Track [Page 13] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[13ページ]RFC5251L1VPN
<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. The globally unique identifiers are under control of network providers. Uniqueness within a service provider administrative domain is sufficient for Basic Mode operation. In the case of multiple provider networks (which is beyond the scope of this document), the globally unique identifier need only be unique and consistent between the those providers. 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:
<PPI、また、CPI>tuplesも特定のVPNに関連している1つ以上のグローバルにユニークな識別子に関連しているに違いありません。 グローバルにユニークな識別子はVPN-ID、ルート目標、またはいかなる他のグローバルにユニークな識別子もコード化できます。 グローバルにユニークな識別子はネットワーク内の提供者で制御されています。 サービスプロバイダーの管理ドメインの中のユニークさはBasic Mode操作に十分です。 グローバルにユニークな識別子が間に複数のプロバイダーネットワークの場合(このドキュメントの範囲にある)では、ユニークであって、一貫しているだけでよい、それらのプロバイダー。 本書では、私たちはすべての自動発見メカニズムに共通のグローバルにユニークな識別子のための一般的なコード化形式を指定します。しかしながら、それぞれの自動発見メカニズムはコード化が分配されている特定の方法と<PPIとの協会を定義して、CPI>tupleは作られています。 VPNに関連しているグローバルにユニークな識別子のコード化は以下の通りです。
+------------------------------------------------+
| L1VPN globally unique identifier (8 octets) |
+------------------------------------------------+
+------------------------------------------------+ | L1VPN、グローバルにユニークな識別子(8つの八重奏)| +------------------------------------------------+
Figure 5: Auto-Discovery Globally Unique Identifier Format
図5: 自動発見しているグローバルにユニークな識別子形式
4.2. CE-to-CE LSP Establishment
4.2. CeからCeへのLSP設立
In order to establish an LSP, a CE needs to identify all other CEs in the CE's L1VPN that it wants to connect to. A CE may already have obtained this information through provisioning or through some other schemes (such schemes are outside the scope of this document).
LSPを設立するために、CEは、それが接続したがっているCEのL1VPNの他のすべてのCEsを特定する必要があります。 CEは食糧を供給することを通して、または、ある他の計画を通して既にこの情報を得たかもしれません(このドキュメントの範囲の外にそのような計画があります)。
Ports associated with a given CE-to-PE link MAY also have other information, in addition to their CPI and PPI, associated with them that describes characteristics and constraints of the channels within these ports, such as encoding supported by the channels, bandwidth of a channel, total unreserved bandwidth within the port, etc. This information could be further augmented with the information about certain capabilities of the service provider network (e.g., support regeneration section overhead (RSOH), Data Communications Channel (DCC) transparency, arbitrary concatenation, etc.). This information is used to ensure that ports at each end of an LSP have compatible characteristics, and that there are sufficient unallocated resources to establish an LSP between these ports.
また、CEからPEへの与えられたリンクに関連しているポートには、他の情報があるかもしれなくて、それらに関連づけられたそれらのCPIとPPIに加えてそれはこれらのポートの中でチャンネルの特性と規制について説明します、チャンネル、チャンネルの帯域幅、ポートの中の総無遠慮な帯域幅などによって支持されたコード化などのように この情報はサービスプロバイダーネットワークのある能力の情報でさらに増大できました(例えば、再生セクションオーバーヘッド(RSOH)、Data Communications Channel(DCC)透明、任意の連結などを支持してください)。 この情報は、LSPの各端のポートにはコンパチブル特性があって、これらのポートの間には、LSPを証明できるくらいの「非-割り当て」られたリソースがあるのを保証するのに使用されます。
It may happen that for a given pair of ports within an L1VPN, each of the CEs connected to these ports would concurrently try to establish an LSP to the other CE. If having a pair of LSPs between a pair of ports is viewed as undesirable, the way to resolve this is to require
L1VPNの中のポートの与えられた組のために、これらのポートに接続されたそれぞれのCEsが同時にもう片方のCEにLSPを設立しようとするのは、起こるかもしれません。 持っているなら、1組のポートの間の1組のLSPsは同じくらい望ましくない状態で見られます、必要とするこれがものである決心への道
Fedyk, et al. Standards Track [Page 14] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[14ページ]RFC5251L1VPN
the CE with the lower value of the CPI to terminate the LSP originated by the CE. This option could be controlled by configuration on the CE devices.
LSPを終えるCPIの下側の値があるCEはCEで由来しました。 CE装置での構成からこのオプションを制御できました。
4.3. Signaling
4.3. シグナリング
In L1VPN BM, a CE needs to be configured with the CPIs of other ports. Once a CE is configured with the CPIs of the other ports within the same L1VPN, which we'll refer to as "target ports", the CE uses a subset of GMPLS signaling to request the provider network to establish an LSP to a target port.
L1VPN BMでは、CEは、他のポートのCPIによって構成される必要があります。 CEが私たちが「目標ポート」を呼ぶつもりであるのと同じL1VPNの中で他のポートのCPIによっていったん構成されると、CEは目標ポートにLSPを設立するようプロバイダーネットワークに要求すると合図するGMPLSの部分集合を使用します。
For inter-CE connectivity, the CE originates a request that contains the CPI of one of its ports that it wants to use for the LSP, and the CPI of the target port. When the PE attached to the CE that originated the request receives the request, the PE identifies the appropriate PIT, and then uses the information in that PIT to find out the PPI associated with the CPI of the target port carried in the request. The PPI should be sufficient for the PE to establish an LSP. Ultimately, the request reaches the CE associated with the target CPI (note that the request still carries the CPI of the CE that originated the request). If the CE associated with the target CPI accepts the request, the LSP is established.
相互CEの接続性に関しては、CEはそれがLSPに使用したがっているポートの1つのCPI、および目標ポートのCPIを含む要求を溯源します。 要求を溯源したCEに取り付けられたPEが要求を受け取ると、PEは、要求で運ばれる目標ポートのCPIに関連しているPPIを見つけるのに適切なPITを特定して、そのPITの情報を使用します。 PEがLSPを証明するように、PPIは十分であるべきです。 結局、要求は目標CPIに関連しているCEに達します(要求がまだ要求を溯源したCEのCPIを運んでいることに注意してください)。 目標CPIに関連しているCEが要請を受け入れるなら、LSPは設立されます。
Note that a CE needs not establish an LSP to every target port that the CE knows about, i.e., it is a local CE policy matter to select a subset of target ports to which that CE will try to establish LSPs.
CEの必要性がCEが知っているあらゆる目標ポートにLSPを設立するというわけではなくて、すなわち、そのCEがLSPsを設立しようとする目標ポートの部分集合を選択するのが、ローカルのCE方針問題であることに注意してください。
The procedures for establishing an individual connection between two corresponding CEs is the same as the procedure specified for GMPLS overlay [RFC4208].
2対応するCEsの間の個々の接続を確立するのが手順がGMPLSに指定したのと同じであるので、手順は[RFC4208]をかぶせました。
4.3.1. Signaling Procedures
4.3.1. シグナリング手順
When an ingress CE sends an RSVP Path message to an ingress PE, the source IP address in the IP packet that carries the message is set to the appropriate CE-CC-Addr, and the destination IP address in the packet is set to the appropriate PE-CC-Addr. When the ingress PE sends back to the ingress CE the corresponding Resv message, the source IP address in the IP packet that carries the message is set to the PE-CC-Addr, and the destination IP address is set to the CE-CC- Addr.
イングレスであるときに、CEはRSVP PathメッセージをイングレスPEに送ります、そして、メッセージを伝えるIPパケットのソースIPアドレスは適切なCE CC Addrに設定されます、そして、パケットの送付先IPアドレスは適切なPE CC Addrに設定されます。 イングレスPEが対応するResvメッセージをイングレスCEに送り返すとき、メッセージを伝えるIPパケットのソースIPアドレスはPEがAddrをCCしているのに設定されます、そして、送付先IPアドレスはCE CC-Addrに設定されます。
Likewise, when an egress PE sends an RSVP Path message to an egress CE, the source IP address in the IP packet that carries the message is set to the appropriate PE-CC-Addr, and the destination IP address in the packet is set to the appropriate CE-CC-Addr. When the egress CE sends back to the egress PE the corresponding Resv message, the
出口であるときに、同様に、PEはRSVP Pathメッセージを出口CEに送ります、そして、メッセージを伝えるIPパケットのソースIPアドレスは適切なPE CC Addrに設定されます、そして、パケットの送付先IPアドレスは適切なCE CC Addrに設定されます。 出口CEが発信するときには、対応するResvメッセージを出口PEに支持してください。
Fedyk, et al. Standards Track [Page 15] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[15ページ]RFC5251L1VPN
source IP address in the IP packet that carries the message is set to the CE-CC-Addr, and the destination IP address is set to the PE-CC- Addr.
メッセージを伝えるIPパケットのソースIPアドレスはCEがAddrをCCしているのに設定されます、そして、送付先IPアドレスはPE CC-Addrに設定されます。
In addition to being used for IP addresses in the IP packet that carries RSVP messages between CE and PE, CE-CC-Addr and PE-CC-Addr are also used in the Next/Previous Hop Address field of the IF_ID RSVP_Hop Object that is carried between CEs and PEs.
それがまた、間にCE、PE、CE CC Addr、およびPE CC AddrがNext/前のHop Address分野で使用されるというRSVPメッセージを伝えるIPパケットのIPアドレスに使用されることに加えて、_ID RSVP_Hop Objectであるなら、それはCEsとPEsの間まで運ばれます。
In the case where a link between CE and PE is a numbered non-bundled link, the CPI and VPN-PPI of that link are used for the Type 1 or 2 TLVs of the IF_ID RSVP_Hop Object that is carried between the CE and PE. In the case where a link between CE and PE is an unnumbered non- bundled link, the CPI and VPN-PPI of that link are used for the IP Address field of the Type 3 TLV. In the case where a link between CE and PE is a bundled link, the CPI and VPN-PPI of that link are used for the IP Address field of the Type 3 TLVs.
CEとPEとのリンクが番号付の非束ねられたリンクである場合に、そのリンクのCPIとVPN-PPIがType1か2TLVsに使用される、_ID RSVP_Hop Objectであるなら、それはCEとPEの間まで運ばれます。 CEとPEとのリンクが無数の非束ねられたリンクである場合では、そのリンクのCPIとVPN-PPIはType3TLVのIP Address分野に使用されます。 CEとPEとのリンクが束ねられたリンクである場合では、そのリンクのCPIとVPN-PPIはType3TLVsのIP Address分野に使用されます。
Additional processing related to unnumbered links is described in
Sections 3 ("Processing the IF_ID RSVP_HOP object") and 4.1
("Unnumbered Forwarding Adjacencies") of RFC 3477 [RFC3477].
無数のリンクに関連する追加処理がセクション3で説明される、(「処理、_ID RSVP_HOPが反対する、」、)、そして、4.1RFC3477(「無数の推進隣接番組」)[RFC3477]。
When an ingress CE originates a Path message to establish an LSP from a particular port on that CE to a particular target port, the CE uses the CPI of its port in the Sender Template object. If the CPI of the target port is an IP address, then the CE uses it in the Session object. And if the CPI of the target port is a <port index, IP address> tuple, then the CE uses the IP address part of the tuple in the Session object, and the whole tuple as the Unnumbered Interface ID subobject in the Explicit Route Object (ERO).
イングレスであるときに、CEはそのCEの上の指定港から特定の目標ポートまでLSPを確立するPathメッセージを溯源して、CEはSender Template物のポートのCPIを使用します。 目標ポートのCPIがIPアドレスであるなら、CEはSession物でそれを使用します。 そして、目標ポートのCPIが<ポートインデックス、IPアドレス>tupleであるなら、CEはUnnumbered Interface ID「副-物」としてExplicit Route Object(ERO)でSession物、および全体のtupleでtupleのIPアドレス部を使用します。
There are two options for RSVP-TE sessions. One option is to have a single RSVP-TE session end to end where the addresses of the customer and the provider are swapped at the PE; this is termed shuffling. The other option is when stitching or hierarchy is used to create two LSP sessions, one between the provider PE(s) and another end-to-end session between the CEs.
2つのオプションがRSVP-TEセッションの間、あります。 1つのオプションは顧客とプロバイダーのアドレスがPEで交換されるところで終わらせるただ一つのRSVP-TEセッション端を持つことです。 これはシャッフルと呼ばれます。 別の選択肢はステッチか階層構造がプロバイダーPE(s)とCEsの間の終わりから終わりへの別のセッションの間で2つのLSPセッション、1を作成するのに使用される時です。
4.3.1.1. Shuffling Sessions
4.3.1.1. シャッフルセッション
Shuffling sessions are used when the desire is to have a single LSP originating at the CE and terminating at the far end CE. The customer addresses are shuffled to provider addresses at the ingress PE, and back to customer addresses at the egress PE by using the mapping provided by the PIT.
願望が独身のLSPがCEで由来して、遠端CEで終わるのを持つことであるときに、シャッフルセッションは使用されています。 顧客の住所はイングレスPEにプロバイダーアドレスにシャッフルされます、出口PEのPITによって提供されたマッピングを使用するのによる顧客の住所に行き帰り。
Fedyk, et al. Standards Track [Page 16] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[16ページ]RFC5251L1VPN
When the Path message arrives at the ingress PE, the PE selects the PIT associated with the L1VPN, and then uses this PIT to map CPIs carried in the Session and the Sender Template objects to the appropriate PPIs. Once the mapping is done, the ingress PE replaces CPIs with these PPIs. As a result, the Session and the Sender Template objects that are carried in the GMPLS signaling within the service provider network carry PPIs, and not CPIs.
PathメッセージがイングレスPEに到着すると、PEは、L1VPNに関連しているPITを選択して、SessionとSender Template物で適切なPPIsまで運ばれたCPIを写像するのにこのPITを使用します。 マッピングがいったん完了していると、イングレスPEはCPIをこれらのPPIsに取り替えます。 その結果、サービスプロバイダーネットワークの中でGMPLSシグナリングで運ばれるSessionとSender Template物はCPIではなく、PPIsを運びます。
At the egress PE, the reverse mapping operation is performed. The PE extracts the ingress/egress PPI values carried in the Sender Template and Session objects (respectively). The egress PE identifies the appropriate PIT to find the appropriate CPI associated with the PPI of the egress CE. Once the mapping is retrieved, the egress PE replaces the ingress/egress PPI values with the corresponding CPI values. As a result, the Session and the Sender Template objects (included in the GMPLS RSVP-TE Path message sent from the egress PE to the egress CE) carry CPIs, and not PPIs.
出口PEでは、操作を写像する逆は実行されます。 PEはSender TemplateとSession物(それぞれ)で運ばれたイングレス/出口PPI値を抽出します。 出口PEは、適切なCPIが出口CEのPPIに関連しているのがわかるために適切なPITを特定します。 マッピングがいったん検索されると、出口PEはイングレス/出口PPI値を対応するCPI値に取り替えます。 その結果、SessionとSender Template物(出口PEから出口CEに送られたGMPLS RSVP-TE Pathメッセージでは、含まれている)はPPIsではなく、CPIを運びます。
Here also, for the GMPLS RSVP-TE Path messages sent from the egress PE to CE, the source IP address (of the IP packet carrying this message) is set to the appropriate PE-CC-Addr, and the destination IP address (of the IP packet carrying this message) is set to the appropriate CE-CC-Addr.
また、ここに、出口PEからCEに送られたGMPLS RSVP-TE Pathメッセージにおいて、ソースIPアドレス(このメッセージを伝えるIPパケットの)は適切なPE CC Addrに設定されます、そして、送付先IPアドレス(このメッセージを伝えるIPパケットの)は適切なCE CC Addrに設定されます。
At this point, the CE's view is a single LSP that is point-to-point between the two CEs with a virtual link between the PE nodes: CE-PE(-)PE-CE. The L1VPN PE nodes have a view of the PE-to-PE LSP segment in all its detail. The PEs MAY filter the RSVP-TE signaling, i.e., remove information about the provider topology and replace it with a view of a virtual link.
ここに、CEの視点はPEノードの間には、仮想のリンクがある状態で2CEsの間で二地点間である独身のLSPです: Ce PE(-)PE Ce。 L1VPN PEノードには、PEからPE LSPへのセグメントの視点がすべての詳細にあります。 PEsはRSVP-TEシグナリングをフィルターにかけるかもしれません、そして、すなわち、プロバイダートポロジーの情報を取り除いてください、そして、それを仮想のリンクの視点に取り替えてください。
This translation of addresses and session IDs is termed shuffling and is driven by the L1VPN Port Information Tables (see Section 4). This MUST be performed for all RSVP-TE messages at the PE edges. In this case, there is one CE-to-CE session.
アドレスとセッションIDに関するこの翻訳は、シャッフルと呼ばれて、L1VPN Port情報Tablesによって追い立てられます(セクション4を見てください)。 PE縁のすべてのRSVP-TEメッセージのためにこれを実行しなければなりません。 この場合、1つのCEからCEへのセッションがあります。
4.3.1.2. Stitched or Nested Sessions
4.3.1.2. ステッチされたか入れ子にされたセッション
Stitching or Nesting options are dependent on the LSP switching types. If the CE-to-CE and PE-to-PE LSPs are identical in switching type and capacity, the LSP MAY be stitched together and the procedures in [RFC5150] apply. If the CE-to-CE LSPs and the PE-to-PE LSPs are of not the same switching type, or are of different but compatible capacity, the LSPs MAY be Nested and the procedures for [RFC4206] apply. As both Stitched and Nested LSP signaling procedures involve a PE-to-PE session establishment compatible with CE session parameters, they are described together.
ステッチかNestingオプションがLSP切り換えタイプに依存しています。 CEへのCEとPE LSPsへのPEが同じであるなら、タイプと容量、LSP MAYを切り換える際に、一緒にステッチされてください。そうすれば、[RFC5150]の手順は適用されます。 CE LSPsへのCEとPE LSPsへのPEがどんな同じ切り換えタイプにはもないか、または異なりましたが、コンパチブル容量のものであるなら、LSPsはNestedであるかもしれません、そして、[RFC4206]のための手順は適用されます。 手順に合図するStitchedとNested LSPの両方がPEからPEへのセッションCEセッションパラメタとのコンパチブル設立にかかわるとき、それらは一緒に説明されます。
Fedyk, et al. Standards Track [Page 17] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[17ページ]RFC5251L1VPN
When the Path Message arrives at the ingress PE, the PE selects the PIT associated with the L1VPN, and then uses this PIT to map CPIs carried in the Session and the Sender Template objects to the appropriate PPIs. Once the mapping is done, a new PE-to-PE session is established with the parameters compatible with the CE session. Upon successful establishment of the PE-to-PE session, the CE signaling request is sent to the egress PE.
Path MessageがイングレスPEに到着すると、PEは、L1VPNに関連しているPITを選択して、SessionとSender Template物で適切なPPIsまで運ばれたCPIを写像するのにこのPITを使用します。 マッピングがいったん完了していると、パラメタは互換性があった状態で、PEからPEへの新しいセッションがCEセッションで確立されます。 PEからPEへのセッションのうまくいっている設立のときに、シグナリングが要求するCEを出口PEに送ります。
At the ingress PE, when stitching and nesting are used, a PE-to-PE session is established. This could be achieved by several means:
ステッチと巣篭もりが使用されているとき、イングレスPEでは、PEからPEへのセッションは確立されます。 いくつかの手段でこれを達成できるでしょう:
- Associating an already established PE-to-PE LSP or Forwarding
Adjacency LSP (FA-LSP) to the destination that meets the
requested parameters.
- PE LSPへの既に確立したPEか要求されたパラメタを満たす目的地へのForwarding Adjacency LSP(FA-LSP)を関連づけます。
- Establishing a compliant PE-to-PE LSP segment.
- PEからPE LSPへの対応するセグメントを確立します。
At this point, the CE's view is a single LSP that is point-to-point between the two CEs with a virtual node between the PE nodes: CE-PE(-)PE-CE. The L1VPN PE nodes have a view of the PE-to-PE LSP segment in all its detail. The PEs do not have to filter the RSVP-TE signaling by removing information about the provider topology because the PE-to-PE signaling is not visible to the CE nodes.
ここに、CEの視点はPEノードの間には、仮想ノードがある状態で2CEsの間で二地点間である独身のLSPです: Ce PE(-)PE Ce。 L1VPN PEノードには、PEからPE LSPへのセグメントの視点がすべての詳細にあります。 PEsは、PEからPEへのシグナリングがCEノードに目に見えないのでプロバイダートポロジーの情報を取り除くことによって、RSVP-TEシグナリングをフィルターにかける必要はありません。
4.3.1.3 Other Signaling
4.3.1.3 他のシグナリング
An ingress PE may receive and potentially reject a Path message that
contains an Explicit Route Object and so cause the switched
connection setup to fail. However, the ingress PE may accept EROs,
which include a sequence of {<ingress PE (strict), egress CE CPI
(loose)>}.
イングレスPEは、受信して、潜在的にExplicit Route Objectを含むPathメッセージを拒絶するので、切り換えられた接続設定に失敗されるかもしれません。 しかしながら、イングレスPEはEROsを受け入れるかもしれません。(EROsは<イングレスPE(厳しい)、出口のCE CPIの(ゆるい)の>の系列を含んでいます)。
- Path message without ERO: when an ingress PE receives a Path
message from an ingress CE that contains no ERO, it MUST calculate
a route to the destination for the PE-to-PE LSP and include that
route in an ERO, before forwarding the Path message. One exception
would be if the egress core node were also adjacent to this core
node.
- EROのない経路メッセージ: イングレスであるときに、PEがEROを全く含まないイングレスCEからPathメッセージを受け取って、PEからPE LSPのために目的地にルートを計算して、EROでそのルートを含めなければなりません、Pathメッセージを転送する前に。 出口コアノードがこのコアノードに隣接してもいるなら、1つの例外がそうでしょうに。
- Path message with ERO: when an ingress PE receives a Path message
from an ingress CE that contains an ERO (of the form detailed
above), the former computes a path to reach the egress PE. It then
inserts this path as part of the ERO before forwarding the Path
message.
- EROがある経路メッセージ: イングレスであるときに、PEはERO(上で詳細なフォームの)を含むイングレスCEからPathメッセージを受け取って、前者は、出口PEに達するように経路を計算します。 そして、Pathメッセージを転送する前に、それはEROの一部としてこの経路を挿入します。
In the case of shuffling, the overlay rules for notification and RRO processing are identical to the User-Network Intercase (UNI) or Overlay Model [RFC4208], which state that Edge PE MAY remove/edit
シャッフルの場合では、通知とRRO処理のためのオーバレイ規則はUser-ネットワークIntercase(UNI)かOverlay Model[RFC4208]と同じです。そのEdge PEはその状態を取り除くか、または編集するかもしれません。
Fedyk, et al. Standards Track [Page 18] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[18ページ]RFC5251L1VPN
Provider Notification and RRO objects when passing the messages to the CEs.
メッセージをCEsに通過するとき、プロバイダーのNotificationとRROは反対します。
4.4. Recovery Procedures
4.4. リカバリ手順
Signaling:
シグナリング:
A CE requests a network-protected LSP (i.e., an LSP that is protected from PE-to-PE) by using the technique described in [RFC4873]. Dynamic identification of merge nodes is supported via the LSP Segment Recovery Flags carried in the Protection object (see Section 6.2 of [RFC4873]).
CEは、[RFC4873]で説明されたテクニックを使用することによって、ネットワークによって保護されたLSP(すなわち、PEからPEから保護されるLSP)を要求します。 マージノードのダイナミックな識別はProtection物で運ばれたLSP Segment Recovery Flagsを通して支持されます([RFC4873]のセクション6.2を見てください)。
Notification:
通知:
A Notify Request object MAY be inserted in Path or Resv messages to indicate the address of a CE that should be notified of an LSP failure. Notifications MAY be requested in both the upstream and downstream directions:
Notify Request物はPathかLSPの故障について通知されるべきであるCEのアドレスを示すResvメッセージに挿入されるかもしれません。 通知は両方の上流の、そして、川下の方向に要求されているかもしれません:
- Upstream notification is indicated via the inclusion of a Notify
Request object in the corresponding Path message.
- 上流の通知は対応するPathメッセージでのNotify Request物の包含で示されます。
- Downstream notification is indicated via the inclusion of a
Notify Request object in the corresponding Resv message.
- 川下の通知は対応するResvメッセージでのNotify Request物の包含で示されます。
A PE receiving a message containing a Notify Request object SHOULD store the Notify Node Address in the corresponding RSVP state block. The PE SHOULD also include a Notify Request object in the outgoing Path or Resv message. The outgoing Notify Node Address MAY be updated based on local policy. This means that a PE, upon receipt of this object from the CE, MAY update the value of the Notify Node Address.
対応するRSVP状態のNotify Node Addressが妨げるNotify Request物のSHOULD店を含むメッセージを受け取るPE。 また、PE SHOULDは出発しているPathかResvメッセージにNotify Request物を含んでいます。 ローカルの方針に基づいて出発しているNotify Node Addressをアップデートするかもしれません。 これは、PEがCEからのこの物を受け取り次第Notify Node Addressの値をアップデートするかもしれないことを意味します。
If the ingress CE includes a Notify Request object into the Path message, the ingress PE MAY replace the received 'Notify Node Address' by its own selected 'Notify Node Address', and in particular the local TE Router_ID. The Notify Request object MAY be carried in Path or Resv messages (Section 7 of [RFC3473]). The format of the Notify Request object is defined in [RFC3473]. Per Section 4.2.1 of [RFC3473], Notify Node Addresses SHALL be set to either IPv4 or IPv6.
イングレスCEがPathメッセージにNotify Request物を含めるなら、イングレスPE MAYは'Node Addressに通知してください'、おいて容認されるおよび特に地方のTE Router_IDを取り替えます。 Notify Request物はPathかResvメッセージ([RFC3473]のセクション7)で運ばれるかもしれません。 Notify Request物の書式は[RFC3473]で定義されます。 .1セクション4.2[RFC3473]、Notify Node Addresses SHALL、IPv4かIPv6のどちらかに設定されてください。
Inclusion of a Notify Request object is used to request the generation of notifications upon failure occurrence but does not guarantee that a Notify message will be generated.
Notify Request物の包含は、失敗発生の通知の世代を要求するのに使用されますが、Notifyメッセージが発生するのを保証しません。
Fedyk, et al. Standards Track [Page 19] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[19ページ]RFC5251L1VPN
5. Security Considerations
5. セキュリティ問題
Security for L1VPNs is covered in [RFC4847] and [RFC5253]. In this document, we discuss the security aspects with respect to the control plane.
L1VPNsのためのセキュリティは[RFC4847]と[RFC5253]でカバーされています。 本書では、私たちは制御飛行機に関してセキュリティ局面について議論します。
The association of a particular port with a particular L1VPN (or to be more precise, with a particular PIT) is a configuration operation, generally done manually by the service provider as part of the service provisioning process. Thus, it cannot be altered via signaling between CE and PE. This means that the signaling cannot be used to deliver L1VPN traffic to the wrong customer. The operator should apply appropriate security mechanisms to the management and configuration process, and should consider data plane verification techniques to protect against accidental misconfiguration. The customer may also apply end-to-end (i.e., CE-to-CE) data plane connectivity tests over the L1VPN connection to detect misconnection. Data plane connectivity testing can be performed using the Link Management Protocol (LMP) [RFC4204].
特定のL1VPNがある指定港の協会は一般に、過程に食糧を供給するサービスの一部としてサービスプロバイダーによって手動で行われた構成操作(特定のPITと共に、より正確になるように)です。 したがって、CEとPEの間で合図することを通してそれを変更できません。 これは、間違った顧客への交通をL1VPNに渡すのにシグナリングを使用できないことを意味します。 オペレータは、適切なセキュリティー対策を管理とコンフィギュレーションプロセスに適用するべきであり、データ飛行機検証のテクニックが偶然のmisconfigurationから守ると考えるべきです。 また、顧客は、付け違いを検出するためにL1VPN接続の上の終わりから終わり(すなわち、CEからCE)へのデータ飛行機接続性テストを適用するかもしれません。 Link Managementプロトコル(LMP)[RFC4204]を使用することでデータ飛行機接続性テストを実行できます。
Note that it is also possible to populate the local part of a PIT using auto-discovery through LMP. LMP may be secured as described in [RFC4204]. Signaling between CE and PE is assumed to be over a private link (for example, in-band or in-fiber) or a private network. Use of a private link makes the CE-to-PE connection secure at the same level as the data link described in the previous paragraphs. The use of a private network assumes that entities outside the network cannot spoof or modify control plane communications between CE and PE. Furthermore, all entities in the private network are assumed to be trusted. Thus, no security mechanisms are required by the protocol exchanges described in this document.
また、LMPを通した自動発見を使用するPITの地方の部分に居住するのも可能であることに注意してください。 LMPは[RFC4204]で説明されるように固定されるかもしれません。 個人的なリンク(例えばバンドかファイバーで)か私設のネットワークの上にCEとPEの間で合図するのがあると思われます。 個人的なリンクの使用で、データ・リンクが前のパラグラフで説明したようにCEからPEとの同じくらいで安全な接続は平らになります。 私設のネットワークの使用は、ネットワークの外における実体がCEとPEとのコントロール飛行機コミュニケーションをだますことができませんし、変更できないと仮定します。 その上、私設のネットワークにおけるすべての実体が信じられると思われます。 したがって、セキュリティー対策は全く本書では説明されたプロトコル交換によって必要とされません。
However, an operator that is concerned about the security of their private control plane network may use the authentication and integrity functions available in RSVP-TE [RFC3473] or utilize IPsec ([RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411]) for the point-to-point signaling between PE and CE. See [MPLS-SEC] for a full discussion of the security options available for the GMPLS control plane.
しかしながら、それらの私設の規制飛行機ネットワークのセキュリティに関して心配しているオペレータは、PEとCEの間で合図するポイントツーポイントに、RSVP-TE[RFC3473]で利用可能な認証と保全機能を使用するか、またはIPsec([RFC4301]、[RFC4302]、[RFC4835]、[RFC4306]、および[RFC2411])を利用するかもしれません。 GMPLS制御飛行機に利用可能なセキュリティオプションの十分な議論に関して[MPLS-SEC]を見てください。
Note further that a private network (e.g., Layer 2 VPN or Layer 3 VPN) might be used to provide control plane connectivity between a PE and more than one CE. In this scenario, it is RECOMMENDED that each L1 VPN customer have its own such private network. Then, the security mechanisms provided by the private network SHOULD be used to ensure security of the control plane communication between a customer and a service provider.
私設のネットワーク(例えば、Layer2VPNかLayer3VPN)がPEと1CEの間にコントロール飛行機の接続性を供給するのに使用されるかもしれないことにさらに注意してください。 このシナリオでは、それぞれのL1 VPN顧客にはそれ自身のそのようなもの私設のネットワークがあるのは、RECOMMENDEDです。 そして、コントロールのセキュリティを確実にするのに個人的なネットワークSHOULDによって使用されるなら、セキュリティー対策は顧客とサービスプロバイダーとのコミュニケーションを平らにします。
Fedyk, et al. Standards Track [Page 20] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[20ページ]RFC5251L1VPN
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3471] エドバーガー、L.、RFC3471、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は機能的な記述を示す」1月2003日
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC3473] エドバーガー、L.、RFC3473、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)は資源予約プロトコル交通工学(RSVP-Te)拡大を示す」1月2003日
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K.、およびY.Rekhter、「資源予約に基づく合図の無数のリンクは議定書を作ります--交通工学(RSVP-Te)」、RFC3477、2003年1月。
[RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4202, October 2005.
[RFC4202]Kompella、K.(エド)、およびY.Rekhter(エド)、「一般化されたマルチプロトコルを支持したルート設定拡大は切り換え(GMPLS)をラベルします」、RFC4202、2005年10月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
October 2005.
[RFC4204] ラング、J.、エド、「リンク管理プロトコル(LMP)」、RFC4204、10月2005日
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206]Kompella(K.とY.Rekhter)は「一般化されたマルチプロトコルラベルスイッチング(GMPLS)交通工学(Te)で切り換えられた経路(LSP)を階層構造とラベルします」、RFC4206、2005年10月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005.
[RFC4208] ツバメ、G.、ドレイク、J.、Ishimatsu、H.、およびY.Rekhter、「一般化されたMultiprotocolはユーザネットワーク・インターフェース(UNI)と切り換え(GMPLS)をラベルします」。 「オーバレイモデルの資源予約プロトコル交通工学(RSVP-Te)サポート」、RFC4208、2005年10月。
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC4873] バーガー、L.、Bryskin、I.、Papadimitriou、D.、およびA.ファレル、「GMPLSセグメント回復」、RFC4873は2007がそうするかもしれません。
[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
"Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering (GMPLS
TE)", RFC 5150, February 2008.
[RFC5150]Ayyangar(A.、Kompella、K.、Vasseur(JP)、およびA.ファレル)は「一般化されたMultiprotocolラベル切り換え交通工学(GMPLS Te)でステッチされる切り換えられた経路をラベルします」、RFC5150、2008年2月。
Fedyk, et al. Standards Track [Page 21] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[21ページ]RFC5251L1VPN
6.2. Informative References
6.2. 有益な参照
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC1700] レイノルズとJ.とJ.ポステル、「規定番号」、RFC1700、1994年10月。
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] エドマニー、E.、RFC3945、「一般化されたマルチプロトコルラベルは(GMPLS)構造を切り換えること」での10月2004日
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella、K.、Rekhter、Y.、およびL.バーガー、「MPLS交通工学(Te)におけるリンクバンドリング」、RFC4201、2005年10月。
[RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1
Virtual Private Networks", RFC 4847, April 2007.
[RFC4847] 竹田、T.、エド、「仮想の兵士がネットワークでつなぐ層1のための枠組みと要件」、RFC4847、4月2007日
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[RFC2411] セイヤーとR.とDoraswamy、N.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC4306] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007.
[RFC4835]Manral、V.、「セキュリティ有効搭載量(超能力)と認証ヘッダー(ああ)をカプセルに入れるための暗号アルゴリズム実現要件」、RFC4835、2007年4月。
[RFC5195] Ould-Brahim, H., Fedyk, D., and Y. Rekhter, "BGP-Based
Auto-Discovery for Layer-1 VPNs", RFC 5195, June 2008.
[RFC5195]オールド-Brahim、H.、Fedyk、D.、およびY.Rekhter、「層-1VPNsのためのBGPベースの自動発見」、RFC5195、2008年6月。
[RFC5252] Bryskin, I. and L. Berger, "OSPF-Based Layer 1 VPN Auto-
Discovery", RFC 5252, July 2008.
[RFC5252] BryskinとI.とL.バーガー、「OSPFベースの層1のVPN自動発見」、RFC5252、2008年7月。
[RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1
Virtual Private Network (L1VPN) Basic Mode", RFC 5253,
July 2008.
[RFC5253] 竹田、T.、エド、「層1の仮想私設網(L1VPN)の基本のモードのための適用性証明」、RFC5253、7月2008日
[MPLS-SEC] Fang, L., Ed., " Security Framework for MPLS and GMPLS
Networks", Work in Progress, February 2008.
[MPLS-SEC] 牙、L.、エド、2月2008、「MPLSのためのセキュリティフレームワークとGMPLSネットワーク」は進行中で働いています。
Fedyk, et al. Standards Track [Page 22] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[22ページ]RFC5251L1VPN
7. Acknowledgments
7. 承認
The authors would like to thank Adrian Farrel, Hamid Ould-Brahim, and Tomonori Takeda for their valuable comments.
作者は彼らの貴重なコメントについてエードリアン・ファレル、ハミドオールド-Brahim、およびTomonori竹田に感謝したがっています。
Sandy Murphy, Charlie Kaufman, Pasi Eronen, Russ Housley, Tim Polk, and Ron Bonica provided input during the IESG review process.
砂地のマーフィー、チャーリー・カウフマン、パシEronen、ラスHousley、ティム・ポーク、およびロンBonicaはIESG吟味の過程の間、入力を提供しました。
Authors' Addresses
作者のアドレス
Don Fedyk Nortel Networks 600 Technology Park Billerica, MA 01821 Phone: +1 (978) 288 3041 EMail: dwfedyk@nortel.com
Parkビルリカ、Technology MA 01821が電話をするFedykノーテルネットワーク600を身につけてください: +1(978) 288 3041はメールされます: dwfedyk@nortel.com
Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 EMail: yakov@juniper.net
Avenueサニーベル、カリフォルニア 94089がメールするヤコフRekhter杜松ネットワーク1194N.マチルダ: yakov@juniper.net
Dimitri Papadimitriou Alcatel-Lucent Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 EMail: Dimitri.Papadimitriou@alcatel-lucent.be
ディミトリPapadimitriouアルカテル透明なフラン。 Wellesplein1、B-2018アントウェルペン(ベルギー)は以下に電話をします。 +32 3 240-8491 メールしてください: Dimitri.Papadimitriou@alcatel-lucent.be
Richard Rabbat Google Inc. 1600 Amphitheatre Pky Mountain View, CA 95054 EMail: rabbat@alum.mit.edu
リチャードRabbat Google Inc.1600円形劇場Pkyマウンテンビュー、カリフォルニア 95054はメールされます: rabbat@alum.mit.edu
Lou Berger LabN Consulting, LLC Phone: +1 301-468-9228 EMail: lberger@labn.net
ルウバーガーLabNが相談して、LLCは以下に電話をします。 +1 301-468-9228 メールしてください: lberger@labn.net
Fedyk, et al. Standards Track [Page 23] RFC 5251 L1VPN Basic Mode July 2008
Fedyk、他 モード2008年7月に基本的な標準化過程[23ページ]RFC5251L1VPN
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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-ipr@ietf.org のIETFに情報を記述してください。
Fedyk, et al. Standards Track [Page 24]
Fedyk、他 標準化過程[24ページ]
一覧
スポンサーリンク
