RFC4847 日本語訳
4847 Framework and Requirements for Layer 1 Virtual Private Networks.T. Takeda, Ed.. April 2007. (Format: TXT=85807 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Takeda, Ed. Request for Comments: 4847 NTT Category: Informational April 2007
Network Working Group T. Takeda, Ed. Request for Comments: 4847 NTT Category: Informational April 2007
Framework and Requirements for Layer 1 Virtual Private Networks
Framework and Requirements for Layer 1 Virtual Private Networks
Status of This Memo
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
Abstract
Abstract
This document provides a framework and service level requirements for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs.
This document provides a framework and service level requirements for Layer 1 Virtual Private Networks (L1VPNs). This framework is intended to aid in developing and standardizing protocols and mechanisms to support interoperable L1VPNs.
The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs.
The document examines motivations for L1VPNs, high level (service level) requirements, and outlines some of the architectural models that might be used to build L1VPNs.
Table of Contents
Table of Contents
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Overview ........................................................5
3.1. Network Topology ...........................................5
3.2. Introducing Layer 1 VPNs ...................................5
3.3. Current Technologies for Dynamic Layer 1 Provisioning ......6
3.4. Relationship with ITU-T ....................................7
4. Motivations .....................................................8
4.1. Basic Layer 1 Services .....................................8
4.1.1. L1VPN for Dynamic Layer 1 Provisioning ..............9
4.2. Merits of L1VPN ............................................9
4.2.1. Customer Merits .....................................9
4.2.2. Provider Merits ....................................10
4.3. L1VPN Deployment Scenarios ................................10
4.3.1. Multi-Service Backbone .............................11
4.3.2. Carrier's Carrier ..................................11
4.3.3. Layer 1 Resource Trading ...........................12
4.3.4. Inter-AS and Inter-SP L1VPNs .......................12
1. Introduction ....................................................3 2. Terminology .....................................................3 3. Overview ........................................................5 3.1. Network Topology ...........................................5 3.2. Introducing Layer 1 VPNs ...................................5 3.3. Current Technologies for Dynamic Layer 1 Provisioning ......6 3.4. Relationship with ITU-T ....................................7 4. Motivations .....................................................8 4.1. Basic Layer 1 Services .....................................8 4.1.1. L1VPN for Dynamic Layer 1 Provisioning ..............9 4.2. Merits of L1VPN ............................................9 4.2.1. Customer Merits .....................................9 4.2.2. Provider Merits ....................................10 4.3. L1VPN Deployment Scenarios ................................10 4.3.1. Multi-Service Backbone .............................11 4.3.2. Carrier's Carrier ..................................11 4.3.3. Layer 1 Resource Trading ...........................12 4.3.4. Inter-AS and Inter-SP L1VPNs .......................12
Takeda Informational [Page 1] RFC 4847 Layer 1 VPN Framework April 2007
Takeda Informational [Page 1] RFC 4847 Layer 1 VPN Framework April 2007
4.3.5. Scheduling Service .................................13
5. Reference Model ................................................14
5.1. Management Systems ........................................15
6. Generic Service Description ....................................15
6.1. CE Construct ..............................................15
6.2. Generic Service Features ..................................16
7. Service Models .................................................16
7.1. Management-Based Service Model ............................17
7.2. Signaling-Based Service Model (Basic Mode) ................17
7.2.1. Overlay Service Model ..............................18
7.3. Signaling and Routing Service Model (Enhanced Mode) .......19
7.3.1. Overlay Extension Service Model ....................20
7.3.2. Virtual Node Service Model .........................20
7.3.3. Virtual Link Service Model .........................21
7.3.4. Per-VPN Peer Service Model .........................22
8. Service Models and Service Requirements ........................22
8.1. Detailed Service Level Requirements .......................24
9. Recovery Aspects ...............................................25
9.1. Recovery Scope ............................................25
9.2. Recovery Resource Sharing Schemes .........................26
10. Control Plane Connectivity ....................................27
10.1. Control Plane Connectivity between a CE and a PE .........27
10.2. Control Plane Connectivity between CEs ...................28
11. Manageability Considerations ..................................29
12. Security Considerations .......................................31
12.1. Types of Information .....................................32
12.2. Security Features ........................................32
12.3. Scenarios ................................................33
13. Acknowledgements ..............................................34
14. Contributors ..................................................34
15. Normative References ..........................................35
16. Informative References ........................................35
4.3.5. Scheduling Service .................................13 5. Reference Model ................................................14 5.1. Management Systems ........................................15 6. Generic Service Description ....................................15 6.1. CE Construct ..............................................15 6.2. Generic Service Features ..................................16 7. Service Models .................................................16 7.1. Management-Based Service Model ............................17 7.2. Signaling-Based Service Model (Basic Mode) ................17 7.2.1. Overlay Service Model ..............................18 7.3. Signaling and Routing Service Model (Enhanced Mode) .......19 7.3.1. Overlay Extension Service Model ....................20 7.3.2. Virtual Node Service Model .........................20 7.3.3. Virtual Link Service Model .........................21 7.3.4. Per-VPN Peer Service Model .........................22 8. Service Models and Service Requirements ........................22 8.1. Detailed Service Level Requirements .......................24 9. Recovery Aspects ...............................................25 9.1. Recovery Scope ............................................25 9.2. Recovery Resource Sharing Schemes .........................26 10. Control Plane Connectivity ....................................27 10.1. Control Plane Connectivity between a CE and a PE .........27 10.2. Control Plane Connectivity between CEs ...................28 11. Manageability Considerations ..................................29 12. Security Considerations .......................................31 12.1. Types of Information .....................................32 12.2. Security Features ........................................32 12.3. Scenarios ................................................33 13. Acknowledgements ..............................................34 14. Contributors ..................................................34 15. Normative References ..........................................35 16. Informative References ........................................35
Takeda Informational [Page 2] RFC 4847 Layer 1 VPN Framework April 2007
Takeda Informational [Page 2] RFC 4847 Layer 1 VPN Framework April 2007
1. Introduction
1. Introduction
This document examines motivations for Layer 1 Virtual Private Networks (L1VPNs), provides high-level (service-level) requirements, and outlines some of the architectural models that might be used to build L1VPNs.
This document examines motivations for Layer 1 Virtual Private Networks (L1VPNs), provides high-level (service-level) requirements, and outlines some of the architectural models that might be used to build L1VPNs.
The objective of the document is mainly to present the requirements and architecture based on the work undertaken within Question 11 of Study Group 13 of the ITU-T.
The objective of the document is mainly to present the requirements and architecture based on the work undertaken within Question 11 of Study Group 13 of the ITU-T.
L1VPNs provide services over layer 1 networks. This document provides a framework for L1VPNs and the realization of the framework by those networks being controlled by Generalized Multi-Protocol Label Switching (GMPLS) protocols.
L1VPNs provide services over layer 1 networks. This document provides a framework for L1VPNs and the realization of the framework by those networks being controlled by Generalized Multi-Protocol Label Switching (GMPLS) protocols.
Use of GMPLS protocols for providing L1VPN services has several advantages, such as:
Use of GMPLS protocols for providing L1VPN services has several advantages, such as:
- Flexible network operation.
- Flexible network operation.
- Use of standardized protocols.
- Use of standardized protocols.
- Use of common control and measurement plane protocols applicable to
various layer 1 networks, including Time Division Multiplexing
(TDM) networks and optical networks.
- Use of common control and measurement plane protocols applicable to various layer 1 networks, including Time Division Multiplexing (TDM) networks and optical networks.
2. Terminology
2. Terminology
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].
The reader is assumed to be familiar with the terminology in [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC3945], [RFC4208], and [RFC4026].
The reader is assumed to be familiar with the terminology in [RFC3031], [RFC3209], [RFC3471], [RFC3473], [RFC4202], [RFC3945], [RFC4208], and [RFC4026].
In this context, a Layer 1 Network is any transport network that has connectivity and/or switching using spatial switching (e.g., incoming port or fiber to outgoing port or fiber), lambda-switching, or time- division-multiplex-switching.
In this context, a Layer 1 Network is any transport network that has connectivity and/or switching using spatial switching (e.g., incoming port or fiber to outgoing port or fiber), lambda-switching, or time- division-multiplex-switching.
A Layer 1 VPN (L1VPN) is a service offered by a core layer 1 network to provide layer 1 connectivity between two or more customer sites, and where the customer has some control over the establishment and type of the connectivity. An alternative definition is simply to say that an L1VPN is a VPN whose data plane operates at layer 1. Further details of the essence of an L1VPN are provided in Section 3.
A Layer 1 VPN (L1VPN) is a service offered by a core layer 1 network to provide layer 1 connectivity between two or more customer sites, and where the customer has some control over the establishment and type of the connectivity. An alternative definition is simply to say that an L1VPN is a VPN whose data plane operates at layer 1. Further details of the essence of an L1VPN are provided in Section 3.
Takeda Informational [Page 3] RFC 4847 Layer 1 VPN Framework April 2007
Takeda Informational [Page 3] RFC 4847 Layer 1 VPN Framework April 2007
In addition, the following new terms are used within this document:
In addition, the following new terms are used within this document:
- Virtual link: A provider network Traffic Engineering (TE) link
advertised to customers in routing information for purposes that
include path computation. A direct data link may or may not exist
between the two end points of a virtual link.
- Virtual link: A provider network Traffic Engineering (TE) link advertised to customers in routing information for purposes that include path computation. A direct data link may or may not exist between the two end points of a virtual link.
- Virtual node: A provider network logical node advertised to
customers in routing information. A virtual node may represent a
single physical node, or multiple physical nodes and the links
between them.
- Virtual node: A provider network logical node advertised to customers in routing information. A virtual node may represent a single physical node, or multiple physical nodes and the links between them.
- VPN end point: A Customer Edge (CE) device's data plane interface,
which is connected to a Provider Edge (PE) device, and which is
part of the VPN membership. Note that a data plane interface is
associated with a TE link end point. For example, if a CE router's
interface is a channelized interface (defined in SONET/SDH), a
channel in the channelized interface can be a data plane interface.
- VPN end point: A Customer Edge (CE) device's data plane interface, which is connected to a Provider Edge (PE) device, and which is part of the VPN membership. Note that a data plane interface is associated with a TE link end point. For example, if a CE router's interface is a channelized interface (defined in SONET/SDH), a channel in the channelized interface can be a data plane interface.
- VPN connection (or connection in the L1VPN context): A connection
between a pair of VPN end points. Note that in some scenarios a
connection may be established between a pair of C (Customer)
devices using this CE-CE VPN connection as a segment or forwarding
adjacency defined in [RFC4206].
- VPN connection (or connection in the L1VPN context): A connection between a pair of VPN end points. Note that in some scenarios a connection may be established between a pair of C (Customer) devices using this CE-CE VPN connection as a segment or forwarding adjacency defined in [RFC4206].
Note that the following terms are aligned with Provider Provisioned VPN (PPVPN) terminology [RFC4026], and in this document, have a meaning in the context of L1VPNs, unless otherwise specified.
Note that the following terms are aligned with Provider Provisioned VPN (PPVPN) terminology [RFC4026], and in this document, have a meaning in the context of L1VPNs, unless otherwise specified.
- CE device: A CE device is a customer device that receives L1VPN
service from the provider. A CE device is connected to at least
one PE device. A CE device can be a variety of devices, for
example, Time Division Multiplexing (TDM) switch, router, and layer
2 switch. A CE device does not have to have the capability to
switch at layer 1, but it is capable of receiving a layer 1 signal
and either switching it or terminating it with adaptation. A CE
device may be attached to one or more C devices on the customer
site, and it may be a host using a layer 1 connection directly.
- CE device: A CE device is a customer device that receives L1VPN service from the provider. A CE device is connected to at least one PE device. A CE device can be a variety of devices, for example, Time Division Multiplexing (TDM) switch, router, and layer 2 switch. A CE device does not have to have the capability to switch at layer 1, but it is capable of receiving a layer 1 signal and either switching it or terminating it with adaptation. A CE device may be attached to one or more C devices on the customer site, and it may be a host using a layer 1 connection directly.
- PE device: A PE device is a provider device that provides L1VPN
service to the customer. A PE device is connected to at least one
CE device. A layer 1 PE device is a TDM switch, an Optical Cross-
Connect (OXC) (see [RFC3945]), or a Photonic Cross-Connect (PXC)
(see [RFC3945]). Alternatively, a PE device may be an Ethernet
Private Line (EPL) type of device that maps Ethernet frames onto
layer 1 connections (by means of Ethernet over TDM etc.).
- PE device: A PE device is a provider device that provides L1VPN service to the customer. A PE device is connected to at least one CE device. A layer 1 PE device is a TDM switch, an Optical Cross- Connect (OXC) (see [RFC3945]), or a Photonic Cross-Connect (PXC) (see [RFC3945]). Alternatively, a PE device may be an Ethernet Private Line (EPL) type of device that maps Ethernet frames onto layer 1 connections (by means of Ethernet over TDM etc.).
Takeda Informational [Page 4] RFC 4847 Layer 1 VPN Framework April 2007
Takeda Informational [Page 4] RFC 4847 Layer 1 VPN Framework April 2007
- P (Provider) device: A P device is a provider device that is
connected only to other provider devices (P or PE devices). A
layer 1 P is a TDM switch, OXC, or PXC.
- P (Provider) device: A P device is a provider device that is connected only to other provider devices (P or PE devices). A layer 1 P is a TDM switch, OXC, or PXC.
- Customer: A customer has authority over a set of CE devices within
the same VPN (e.g., the owner of CE devices). Note that a customer
may outsource the management of CE devices to other organizations,
including to the provider itself.
- Customer: A customer has authority over a set of CE devices within the same VPN (e.g., the owner of CE devices). Note that a customer may outsource the management of CE devices to other organizations, including to the provider itself.
- Provider: A provider has authority over the management of the
provider network.
- Provider: A provider has authority over the management of the provider network.
- Membership information: A list of CE-PE TE link addresses belonging
to the same VPN. Membership information contains the association
of a CE, a PE, and a VPN.
- Membership information: A list of CE-PE TE link addresses belonging to the same VPN. Membership information contains the association of a CE, a PE, and a VPN.
3. Overview
3. Overview
3.1. Network Topology
3.1. Network Topology
The layer 1 network, made of OXCs, TDM switches, or PXCs may be seen as consisting of PE devices that give access from outside of the network, and P devices that operate only within the core of the network. Similarly, outside the layer 1 network is the customer network consisting of C devices with access to the layer 1 network made through CE devices.
The layer 1 network, made of OXCs, TDM switches, or PXCs may be seen as consisting of PE devices that give access from outside of the network, and P devices that operate only within the core of the network. Similarly, outside the layer 1 network is the customer network consisting of C devices with access to the layer 1 network made through CE devices.
A CE and PE are connected by one or more links. A CE may also be connected to more than one PE, and a PE may have more than one CE connected to it.
A CE and PE are connected by one or more links. A CE may also be connected to more than one PE, and a PE may have more than one CE connected to it.
A layer 1 connection is provided between a pair of CEs. Such a connection follows the hierarchy defined in [RFC4206]. That is, a CE-CE connection may be nested in a lower layer connection (e.g., VC3 connection over STM1 connection). Likewise, the switching capabilities of the interfaces of the CEs, PEs, and Ps on which a connection is routed, follow the hierarchy defined in [RFC4206].
A layer 1 connection is provided between a pair of CEs. Such a connection follows the hierarchy defined in [RFC4206]. That is, a CE-CE connection may be nested in a lower layer connection (e.g., VC3 connection over STM1 connection). Likewise, the switching capabilities of the interfaces of the CEs, PEs, and Ps on which a connection is routed, follow the hierarchy defined in [RFC4206].
3.2. Introducing Layer 1 VPNs
3.2. Introducing Layer 1 VPNs
The concept of a PPVPN has been established through many previous documents such as [RFC4664] and [RFC4110]. Terminology for PPVPNs is set out in [RFC4026] with special reference to layer 2 and layer 3 VPNs.
The concept of a PPVPN has been established through many previous documents such as [RFC4664] and [RFC4110]. Terminology for PPVPNs is set out in [RFC4026] with special reference to layer 2 and layer 3 VPNs.
The realization of L1VPNs can be based on extensions of the concepts of the PPVPN to the layer 1 network. It must be understood that meeting the requirements set out in this document may necessitate
The realization of L1VPNs can be based on extensions of the concepts of the PPVPN to the layer 1 network. It must be understood that meeting the requirements set out in this document may necessitate
Takeda Informational [Page 5] RFC 4847 Layer 1 VPN Framework April 2007
Takeda Informational [Page 5] RFC 4847 Layer 1 VPN Framework April 2007
extensions to the existing mechanisms both for the control plane within the layer 1 network and for service provisioning at the edge of the network (CE and PE devices). It is at the interface between CE and PE devices that the L1VPN service is provided.
extensions to the existing mechanisms both for the control plane within the layer 1 network and for service provisioning at the edge of the network (CE and PE devices). It is at the interface between CE and PE devices that the L1VPN service is provided.
Note that the fundamental difference between L1VPNs and L2/L3 VPNs is that in L1VPNs, data plane connectivity does not guarantee control plane connectivity (and vice versa). But CE-PE control plane connectivity is required for L1VPN services provisioned through the control plane, and CE-CE data plane connectivity is maintained by signaling mechanisms based on this control plane connectivity. Furthermore, the provision of CE-CE control plane connectivity over the provider network is also required for certain levels of L1VPN service, and this can be achieved by the exchange of control packets between CEs over the control plane of the provider network. This aspect is discussed further in Section 10.2.
Note that the fundamental difference between L1VPNs and L2/L3 VPNs is that in L1VPNs, data plane connectivity does not guarantee control plane connectivity (and vice versa). But CE-PE control plane connectivity is required for L1VPN services provisioned through the control plane, and CE-CE data plane connectivity is maintained by signaling mechanisms based on this control plane connectivity. Furthermore, the provision of CE-CE control plane connectivity over the provider network is also required for certain levels of L1VPN service, and this can be achieved by the exchange of control packets between CEs over the control plane of the provider network. This aspect is discussed further in Section 10.2.
3.3. Current Technologies for Dynamic Layer 1 Provisioning
3.3. Current Technologies for Dynamic Layer 1 Provisioning
Pre-existing efforts at standardization have focused on the provision of dynamic connections within the layer 1 network (signaling and routing) and the definition of interfaces for requesting services between the user and the layer 1 network over the User-Network Interface (UNI), and between networks across the External Network- Network Interface (E-NNI) (see [RFC3945], [RFC4208], [RFC4139], and [RFC4258]).
Pre-existing efforts at standardization have focused on the provision of dynamic connections within the layer 1 network (signaling and routing) and the definition of interfaces for requesting services between the user and the layer 1 network over the User-Network Interface (UNI), and between networks across the External Network- Network Interface (E-NNI) (see [RFC3945], [RFC4208], [RFC4139], and [RFC4258]).
Current UNIs include features to facilitate requests for end-to-end (that is, CE to CE) services that include the specification of constraints such as explicit paths, bandwidth requirements, protection needs, and (of course) destinations.
Current UNIs include features to facilitate requests for end-to-end (that is, CE to CE) services that include the specification of constraints such as explicit paths, bandwidth requirements, protection needs, and (of course) destinations.
Current E-NNIs include features to exchange routing information, as well as to facilitate requests for end-to-end services.
Current E-NNIs include features to exchange routing information, as well as to facilitate requests for end-to-end services.
The UNIs and E-NNIs may be applied in the context of L1VPNs. For example, the UNI may be applied between the CE and the PE, and the E-NNI may be applied between PEs (inter-AS/SP L1VPNs), or between the CE and the PE.
The UNIs and E-NNIs may be applied in the context of L1VPNs. For example, the UNI may be applied between the CE and the PE, and the E-NNI may be applied between PEs (inter-AS/SP L1VPNs), or between the CE and the PE.
However, the existing UNI and E-NNI specifications do not provide sufficient parameters to support VPNs without some additions. For example, there is no way to distinguish between control messages received over a shared control link (i.e., a control link shared by multiple VPNs) at a UNI/E-NNI, and these messages must be disambiguated to determine the L1VPN to which they apply. A control link is an IP link used for establishing a control channel between nodes.
However, the existing UNI and E-NNI specifications do not provide sufficient parameters to support VPNs without some additions. For example, there is no way to distinguish between control messages received over a shared control link (i.e., a control link shared by multiple VPNs) at a UNI/E-NNI, and these messages must be disambiguated to determine the L1VPN to which they apply. A control link is an IP link used for establishing a control channel between nodes.
Takeda Informational [Page 6] RFC 4847 Layer 1 VPN Framework April 2007
Takeda Informational [Page 6] RFC 4847 Layer 1 VPN Framework April 2007
Another example is that there is no clearly defined way of distributing membership information to be used in combination with UNI/E-NNI. This function is necessary in order to discover the existence and location of the CEs to be connected by L1 connections. Distribution of membership information is typically done by the provider, and may be realized by mechanisms such as static provisioning, or by piggybacking on routing protocols (e.g., see Section 4.2.1 of [RFC4110]). Note that the method chosen for distribution of membership information depends on the solution used for supporting L1VPNs, which is outside of the scope of this document.
Another example is that there is no clearly defined way of distributing membership information to be used in combination with UNI/E-NNI. This function is necessary in order to discover the existence and location of the CEs to be connected by L1 connections. Distribution of membership information is typically done by the provider, and may be realized by mechanisms such as static provisioning, or by piggybacking on routing protocols (e.g., see Section 4.2.1 of [RFC4110]). Note that the method chosen for distribution of membership information depends on the solution used for supporting L1VPNs, which is outside of the scope of this document.
Furthermore, customer addressing realms may overlap with each other, and may also overlap with the service provider addressing realm. This requires address mapping mechanisms, but such mechanisms are not well defined in existing UNI/E-NNI specifications.
Furthermore, customer addressing realms may overlap with each other, and may also overlap with the service provider addressing realm. This requires address mapping mechanisms, but such mechanisms are not well defined in existing UNI/E-NNI specifications.
Lastly, there is no clearly defined way to restrict connectivity among CEs (or over a UNI/E-NNI). In addition, E-NNIs allow routing information exchange, but there is no clearly defined way to allow limited routing information exchange (i.e., a specific set of routing information is distributed to a specific set of CEs).
Lastly, there is no clearly defined way to restrict connectivity among CEs (or over a UNI/E-NNI). In addition, E-NNIs allow routing information exchange, but there is no clearly defined way to allow limited routing information exchange (i.e., a specific set of routing information is distributed to a specific set of CEs).
In order for L1VPNs to be supported in a fully functional manner, these additional capabilities and other requirements set out later in this document must be addressed.
In order for L1VPNs to be supported in a fully functional manner, these additional capabilities and other requirements set out later in this document must be addressed.
Note that inter-AS/SP L1VPNs require additional analysis beyond the focus of this document.
Note that inter-AS/SP L1VPNs require additional analysis beyond the focus of this document.
3.4. Relationship with ITU-T
3.4. Relationship with ITU-T
The foundation of this document is based on the work of the ITU-T Study Group 13, Question 11, such as [Y.1312] and [Y.1313]. This group has been researching and specifying both the requirements and the architecture of L1VPNs for some time. In this context, the foundation of this document is a representation of the findings of the ITU-T, and a presentation of those findings in terms and format that are familiar to the IETF.
The foundation of this document is based on the work of the ITU-T Study Group 13, Question 11, such as [Y.1312] and [Y.1313]. This group has been researching and specifying both the requirements and the architecture of L1VPNs for some time. In this context, the foundation of this document is a representation of the findings of the ITU-T, and a presentation of those findings in terms and format that are familiar to the IETF.
In particular, this document is limited to the areas of concern of the IETF. That is, it is limited to layer 1 networks that utilize IP as the underlying support for their control plane.
In particular, this document is limited to the areas of concern of the IETF. That is, it is limited to layer 1 networks that utilize IP as the underlying support for their control plane.
The foundation of this document presents the requirements and architectures developed within the ITU-T for better understanding within the IETF and to further cooperation between the two bodies.
The foundation of this document presents the requirements and architectures developed within the ITU-T for better understanding within the IETF and to further cooperation between the two bodies.
Takeda Informational [Page 7] RFC 4847 Layer 1 VPN Framework April 2007
Takeda Informational [Page 7] RFC 4847 Layer 1 VPN Framework April 2007
Some work related to the L1VPN solution space has already been done within the IETF.
Some work related to the L1VPN solution space has already been done within the IETF.
4. Motivations
4. Motivations
The general benefits and desirability of VPNs have been described many times and in many places ([RFC4110] and [RFC4664]). This document does not dwell on the merits of VPNs as such, but focuses entirely on the applicability of the VPN concept to layer 1 networks.
The general benefits and desirability of VPNs have been described many times and in many places ([RFC4110] and [RFC4664]). This document does not dwell on the merits of VPNs as such, but focuses entirely on the applicability of the VPN concept to layer 1 networks.
Similarly, the utility and value of a control plane for the configuration, management, and operation of a layer 1 network is well-rehearsed [RFC3945].
Similarly, the utility and value of a control plane for the configuration, management, and operation of a layer 1 network is well-rehearsed [RFC3945].
4.1. Basic Layer 1 Services
4.1. Basic Layer 1 Services
Basic layer 1 services may be characterized in terms that include:
Basic layer 1 services may be characterized in terms that include:
- Connectivity: Between a pair of CEs.
- Connectivity: Between a pair of CEs.
- Capacity: For example, the bit rate for a TDM service or the
capacity of a lambda.
- Capacity: For example, the bit rate for a TDM service or the capacity of a lambda.
- Transparency: For example, for an SDH network, overhead
transparency.
- Transparency: For example, for an SDH network, overhead transparency.
- Availability: The percentage of time that the offered service meets
the criteria that the provider defines, possibly agreed with each
customer. To achieve the required level of availability for the
customer connections the service provider's network may use
restoration or protected resources [RFC4427].
- Availability: The percentage of time that the offered service meets the criteria that the provider defines, possibly agreed with each customer. To achieve the required level of availability for the customer connections the service provider's network may use restoration or protected resources [RFC4427].
- Performance: The quality of the service delivered to customers,
e.g., the number of error-seconds per month.
- Performance: The quality of the service delivered to customers, e.g., the number of error-seconds per month.
The layer 1 services may be categorized based on the combination of connectivity features (data plane) and service control capability features (control plane) available to the customer. A CE is associated with the service interface between a customer site and the provider network, and the categorization can be seen in the context of this service interface as follows.
The layer 1 services may be categorized based on the combination of connectivity features (data plane) and service control capability features (control plane) available to the customer. A CE is associated with the service interface between a customer site and the provider network, and the categorization can be seen in the context of this service interface as follows.
1. A single connection between a pair of CEs.
1. A single connection between a pair of CEs.
- Static Service:
The classic private line service achieved through a permanent
connection.
- Static Service: The classic private line service achieved through a permanent connection.
Takeda Informational [Page 8] RFC 4847 Layer 1 VPN Framework April 2007
Takeda Informational [Page 8] RFC 4847 Layer 1 VPN Framework April 2007
- Dynamic Service:
Either a switched connection service, or a customer-controlled
soft permanent connection service (i.e., the customer is in
control of when the signaled part is established).
- Dynamic Service: Either a switched connection service, or a customer-controlled soft permanent connection service (i.e., the customer is in control of when the signaled part is established).
2. Multiple connections among a set of CEs.
2. Multiple connections among a set of CEs.
- Static Service:
A private network service consisting of a mesh of permanent
connections.
- Static Service: A private network service consisting of a mesh of permanent connections.
- Dynamic Service:
A dynamic private network service consisting of any combination
of switched connection services and customer-controlled soft
permanent connection services.
- Dynamic Service: A dynamic private network service consisting of any combination of switched connection services and customer-controlled soft permanent connection services.
For service types 1 and 2, connections are point-to-point, and can be permanent, soft-permanent, or switched. For a static service, the management plane of the provider network is responsible for the management of both the network infrastructure and the end-user connections. For dynamic services, the management plane of the provider network is only responsible for the configuration of the infrastructure; end-user connections are established dynamically via the control plane of the provider network upon customer request.
For service types 1 and 2, connections are point-to-point, and can be permanent, soft-permanent, or switched. For a static service, the management plane of the provider network is responsible for the management of both the network infrastructure and the end-user connections. For dynamic services, the management plane of the provider network is only responsible for the configuration of the infrastructure; end-user connections are established dynamically via the control plane of the provider network upon customer request.
This document does not preclude other advanced services and topology support, such as point-to-multipoint (P2MP) services, as part of the layer 1 services, but these are for further study.
This document does not preclude other advanced services and topology support, such as point-to-multipoint (P2MP) services, as part of the layer 1 services, but these are for further study.
4.1.1. L1VPN for Dynamic Layer 1 Provisioning
4.1.1. L1VPN for Dynamic Layer 1 Provisioning
Private network services in the second category in Section 4.1 can be enhanced so that multiple private networks are supported across the layer 1 network as virtual private networks. These are Layer 1 Virtual Private Networks (L1VPNs). Note that the first category in Section 4.1 would include L1VPNs with only two CEs as a special case.
Private network services in the second category in Section 4.1 can be enhanced so that multiple private networks are supported across the layer 1 network as virtual private networks. These are Layer 1 Virtual Private Networks (L1VPNs). Note that the first category in Section 4.1 would include L1VPNs with only two CEs as a special case.
Compared to the first category of service, the L1VPN service has features such as connectivity restriction, a separate policy, and distribution of membership information applied to a specific group.
Compared to the first category of service, the L1VPN service has features such as connectivity restriction, a separate policy, and distribution of membership information applied to a specific group.
4.2. Merits of L1VPN
4.2. Merits of L1VPN
4.2.1. Customer Merits
4.2.1. Customer Merits
From the customer's perspective, there are two main benefits to a L1VPN. These benefits apply over and above the advantages of access to a dynamically provisioned network.
From the customer's perspective, there are two main benefits to a L1VPN. These benefits apply over and above the advantages of access to a dynamically provisioned network.
Takeda Informational [Page 9] RFC 4847 Layer 1 VPN Framework April 2007
Takeda Informational [Page 9] RFC 4847 Layer 1 VPN Framework April 2007
- The customer can outsource the direct management of a layer 1
network by placing the VPN management in the control of a third
party. This frees the customer from the need to configure and
manage the connectivity information for the CEs that participate in
the VPN.
- The customer can outsource the direct management of a layer 1 network by placing the VPN management in the control of a third party. This frees the customer from the need to configure and manage the connectivity information for the CEs that participate in the VPN.
- The customer can make small-scale use of a layer 1 network. So,
for example, by sharing the layer 1 network infrastructure with
many other users, the customer sites can be connected together
across the layer 1 network without bearing the full cost of
deploying and managing the layer 1 network.
- The customer can make small-scale use of a layer 1 network. So, for example, by sharing the layer 1 network infrastructure with many other users, the customer sites can be connected together across the layer 1 network without bearing the full cost of deploying and managing the layer 1 network.
To some extent, the customer may also gain from the provider's benefits (see below). That is, if the provider is able to extract more value from the layer 1 network, the customer will benefit from lower priced services that are better tailored to the customer's needs.
To some extent, the customer may also gain from the provider's benefits (see below). That is, if the provider is able to extract more value from the layer 1 network, the customer will benefit from lower priced services that are better tailored to the customer's needs.
4.2.2. Provider Merits
4.2.2. Provider Merits
The provider benefits from the customer's perception of benefits.
The provider benefits from the customer's perception of benefits.
In particular, the provider can build on dynamic, on-demand services by offering new VPN services and off-loading the CE-to-CE configuration requirements from the customers.
In particular, the provider can build on dynamic, on-demand services by offering new VPN services and off-loading the CE-to-CE configuration requirements from the customers.
Additionally, a more flexible VPN structure applied to the layer 1 network allows the provider to make more comprehensive use of the spare (that is, previously unused) resources within the network. This could be achieved by applying a network model where the provider is responsible for deciding how resources are used and for provisioning of the connection through the layer 1 network.
Additionally, a more flexible VPN structure applied to the layer 1 network allows the provider to make more comprehensive use of the spare (that is, previously unused) resources within the network. This could be achieved by applying a network model where the provider is responsible for deciding how resources are used and for provisioning of the connection through the layer 1 network.
4.3. L1VPN Deployment Scenarios
4.3. L1VPN Deployment Scenarios
In large carrier networks providing various kinds of service, it is often the case that multiple service networks are supported over a shared transport network. By applying L1VPNs, multiple internal service networks (which may be managed and operated separately) can be supported over a shared layer 1 transport network controlled and managed using GMPLS. In addition, L1VPNs can support capabilities to offer innovative services to external clients.
In large carrier networks providing various kinds of service, it is often the case that multiple service networks are supported over a shared transport network. By applying L1VPNs, multiple internal service networks (which may be managed and operated separately) can be supported over a shared layer 1 transport network controlled and managed using GMPLS. In addition, L1VPNs can support capabilities to offer innovative services to external clients.
Some more specific deployment scenarios are as follows.
Some more specific deployment scenarios are as follows.
Takeda Informational [Page 10] RFC 4847 Layer 1 VPN Framework April 2007
Takeda Informational [Page 10] RFC 4847 Layer 1 VPN Framework April 2007
4.3.1. Multi-Service Backbone
4.3.1. Multi-Service Backbone
A multi-service backbone is characterized such that each service department of a carrier that receives the carrier's L1VPN service provides a different kind of higher-layer service. The customer receiving the L1VPN service (i.e., each service department) can offer its own services, whose payloads can be any layer (e.g., ATM, IP, TDM). The layer 1 transport network and each service network belong to the same organization, but may be managed separately. From the L1VPN service provider's point of view, these services are not visible and are not part of the L1VPN service. That is, the type of service being carried within the layer 1 payload is not known by the service provider.
マルチサービスバックボーンが特徴付けられるので、キャリヤーのL1VPNサービスを受けるキャリヤーの各アフターサービス部門は異種の、より高い層のサービスを提供します。 L1VPNサービス(すなわち各アフターサービス部門)を受ける顧客はペイロードがどんな層であるかもしれない(例えば、ATM、IP、TDM)それ自身のサービスも提供できます。 層1の転送ネットワークとそれぞれのサービスネットワークは、同じ組織に属しますが、別々に経営されるかもしれません。 L1VPNサービスプロバイダーの観点から、これらのサービスは、目に見えないで、またL1VPNサービスの一部ではありません。 すなわち、層の1ペイロードの中に提供されるサービスのタイプはサービスプロバイダーによって知られていません。
The benefit is that the same layer 1 transport network resources are shared by multiple services. A large capacity backbone network (data plane) can be built economically by having the resources shared by multiple services usually with flexibility to modify topologies, while separating the control functions for each service department. Thus, each customer can select a specific set of features that are needed to provide their own service.
利益は同じ層1の輸送ネットワーク資源が複数のサービスで共有されるということです。 各アフターサービス部門にコントロール機能を切り離している間、topologiesを変更するために複数のサービスで通常柔軟性とリソースを共有させることによって、大容量バックボーンネットワーク(データ飛行機)を経済的に造ることができます。 したがって、各顧客はそれら自身のサービスを提供するのに必要である特定のセットの特徴を選択できます。
Note that it is also possible to control and manage these service networks and the layer 1 transport network by using GMPLS in the integrated model [RFC3945] instead of using L1VPNs. However, using L1VPNs is beneficial in the following points:
また、L1VPNsを使用することの代わりに統合モデル[RFC3945]でGMPLSを使用することによってこれらのサービスネットワークと層1の転送ネットワークを制御して、経営するのも可能であることに注意してください。 しかしながら、L1VPNsを使用するのは以下のポイントで有益です:
- Independent address space for each of the service networks.
- それぞれのサービスネットワークのための独立しているアドレス空間。
- Network isolation (topology information isolation, fault isolation
among service networks).
- 分離(トポロジー情報分離、サービスネットワークの中の欠点分離)をネットワークでつないでください。
- Independent layer 1 resource view for each of the service networks.
- それぞれのサービスネットワークのための独立している層1のリソース視点。
- Independent policies that could be applied for each of the service
networks.
- それぞれ申し込むことができたサービスネットワークの独立している方針。
These points may apply to the management plane functionalities as well as to the control plane functionalities.
これらのポイントはコントロール飛行機の機能性に関してまた、管理飛行機の機能性に適用されるかもしれません。
4.3.2. Carrier's Carrier
4.3.2. キャリヤーのキャリヤー
A carrier's carrier is characterized such that one carrier that receives another carrier's L1VPN service provides its own services. In this scenario, two carriers are in different organizations. It is, therefore, expected that the information provided at the service demarcation points is more limited than in the multi-service backbone case. Similarly, less control of the L1VPN service is given at the
キャリヤーのキャリヤーが描写されるので、別のキャリヤーのL1VPNサービスを受ける1個のキャリヤーがそれ自身のサービスを提供します。 このシナリオでは、2個のキャリヤーが異なった組織中です。 したがって、サービス画定ポイントで提供された情報がマルチサービスバックボーンケースより限られていると予想されます。 同様に、より少ないL1VPNサービスの支配力を与えます。
Takeda Informational [Page 11] RFC 4847 Layer 1 VPN Framework April 2007
[11ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
service demarcation points. For example, customers of an L1VPN service receive:
サービス画定は指します。 例えば、L1VPNサービスの顧客は受信します:
- A more limited view of the L1VPN service provider network.
- L1VPNサービスプロバイダーネットワークの、より限られた視点。
- More limited control over the L1VPN service provider network.
- 以上はL1VPNサービスプロバイダーネットワークのコントロールを制限しました。
One of the merits is that each carrier can concentrate on a specific service. For example, the customer of the L1VPN service may focus on L3 services, e.g., providing secure access to the Internet, leaving the L1VPN provider to focus on the layer 1 service, e.g., providing a long-haul bandwidth between cities. The L1VPN customer can construct its own network using layer 1 resources supplied by the L1VPN provider, usually with flexibility to modify topologies, while separating the control functions for each customer carrier.
長所の1つは各キャリヤーが特定のサービスに集中できるということです。 例えば、L1VPNサービスの顧客はL3サービスに焦点を合わせるかもしれません、例えば、インターネットへの提供の安全なアクセス、1つのサービスの層に焦点を合わせるL1VPNプロバイダー、例えば、提供に都市の間の長期帯域幅を残して。 L1VPN顧客は、それぞれの顧客キャリヤーのためにコントロール機能を切り離している間、topologiesを変更するのに通常、柔軟性と共にL1VPNプロバイダーによって提供された層1のリソースを使用することでそれ自身のネットワークを構成できます。
4.3.3. Layer 1 Resource Trading
4.3.3. 層1のリソース取り引き
In addition to the scenarios where the second tier service provider is using a single core service provider as mentioned in Section 4.3.2, it is possible for the second tier provider to receive services from more than one core service provider. In this scenario, there are some benefits for the second tier service provider such as route redundancy and dynamic carrier selection based on the price.
第2代層のサービスプロバイダーがセクション4.3.2で言及されるように単芯サービスプロバイダーを使用しているシナリオに加えて、2番目の層のプロバイダーが1つ以上のコアサービスプロバイダーからサービスを受けるのは、可能です。 このシナリオには、第2代層のサービスプロバイダーのための価格に基づくルート冗長やダイナミックなキャリヤー選択などのいくつかの恩恵があります。
The second tier service provider can support a function that enables a layer 1 resource trading service. Using resource information published by its core service providers, a second tier service provider can decide how to best use the core providers. For example, if one core service provider is no longer able to satisfy requests for service, an alternate service provider can be used. Or the second tier service provider could choose to respond to price changes of service over time.
第2代層のサービスプロバイダーは1つのリソースの取り引きサービスを層を可能にする機能にサポートすることができます。 コアサービスプロバイダーによって発表されたリソース情報を使用して、2番目の層のサービスプロバイダーはコアプロバイダーを最もよく使用する方法を決めることができます。 例えば、1つのコアサービスプロバイダーがもうサービスを求める要望に応じることができないなら、代替のサービスプロバイダーを使用できます。 または、第2代層のサービスプロバイダーは、サービスオーバー時間の変化に値を付けるために応じるのを選ぶことができました。
Another example of second tier service provider use is to reduce exposure to failures in each provider (i.e., to improve availability).
2番目の層のサービスプロバイダー使用に関する別の例は各プロバイダー(すなわち、有用性を改良する)における失敗に暴露を減少させることです。
4.3.4. Inter-AS and Inter-SP L1VPNs
4.3.4. 相互、相互SP L1VPNs
In addition to the scenarios where a single connection between two CEs is routed over a single service provider as mentioned in Section 4.3.2, it is possible that a connection is routed over multiple ASes within a service provider (called inter-AS L1VPN) or over multiple service providers (called inter-SP L1VPN).
2CEsの間の単独結合がセクション4.3.2で言及されるようにただ一つのサービスプロバイダーの上に発送されるシナリオに加えて、接続がサービスプロバイダーの中の複数のASes(相互AS L1VPNと呼ばれる)の上、または、複数のサービスプロバイダー(相互SP L1VPNと呼ばれる)の上に発送されるのは、可能です。
The inter-AS L1VPN scenario can be used to construct a single L1VPN from network resources administered by different domains of a single
シングルの異なったドメインによって管理されたネットワーク資源から独身のL1VPNを組み立てるのに相互AS L1VPNシナリオを使用できます。
Takeda Informational [Page 12] RFC 4847 Layer 1 VPN Framework April 2007
[12ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
service provider. These administrative domains might not usually have a collaborative relationship at layer 1, and so the inter-AS L1VPN offers a new business model for joint delivery of services to a customer. Consideration of inter-AS L1VPNs requires further analysis beyond the scope of this document.
サービスプロバイダー。 これらの管理ドメインが層1に通常協力的な関係を持っていないかもしれないので、相互AS L1VPNは顧客に対するサービスの共同配送のために新しいビジネスモデルを提供します。 相互AS L1VPNsの考慮はこのドキュメントの範囲を超えてさらなる分析を必要とします。
The inter-SP scenario can be used to construct a single L1VPN from services provided by multiple regional providers. There could be a variety of business relationships among providers and customers, and this scenario contains many more manageability, security, privacy, policy, and commercial issues than the more simple inter-AS L1VPN case. Consideration of inter-SP L1VPN requires further analysis beyond the scope of this document.
複数の地方のプロバイダーによって提供されたサービスから独身のL1VPNを組み立てるのに相互SPシナリオを使用できます。 プロバイダーと顧客の中にさまざまな取引関係があるかもしれなくて、このシナリオは、より簡単な相互AS L1VPNケースよりずっと多くの管理可能性、セキュリティ、プライバシー、方針、および商業問題を含んでいます。 相互SP L1VPNの考慮はこのドキュメントの範囲を超えてさらなる分析を必要とします。
4.3.5. Scheduling Service
4.3.5. スケジューリングサービス
In some deployment scenarios, customers of L1VPN services may wish to set up layer 1 connections not on-demand, but at a planned time in the future. Or, even though customers of L1VPN services may wish to use layer 1 connections on-demand, they can tolerate some delay, for example, due to lack of resources at that moment.
いくつかの展開シナリオでは、層1の接続に要求次第でなくセットしますが、L1VPNサービスの顧客は未来の計画された時にセットしたがっているかもしれません。 または、L1VPNサービスの顧客は要求次第で層1の接続を使用したがっているかもしれませんが、例えば、彼らはその瞬間に財源不足のため何らかの遅れを許容できます。
In those scenarios, the provider can reserve bandwidth at a specified time in the future, and can establish the VPN connections according to a schedule. This makes it possible to use bandwidth more efficiently over time (i.e., support more demand). This service, the scheduling service, may be used to support customers who use layer 1 connections for data backup applications, content delivery applications, and some other applications.
それらのシナリオに、プロバイダーは、指定の時間に将来帯域幅を控えることができて、スケジュール通りにVPN接続を確立できます。 これで、時間がたつにつれてより効率的に帯域幅を使用するのは可能になります(すなわち、より多くの要求をサポートしてください)。 このサービス(スケジューリングサービス)は、データバックアップアプリケーション、内容物配送アプリケーション、およびある他のアプリケーションのために層を使用する顧客に1つの接続をサポートするのに利用されるかもしれません。
Furthermore, customers may be able to specify when to release layer 1 connections in advance. By considering this information, the provider may be able to further engineer scheduling, which leads to still more efficient bandwidth usage.
その上、顧客は、あらかじめいつ層1の接続を釈放するかを指定できるかもしれません。 この情報を考えることによって、プロバイダーはさらなる技術者スケジューリングにできるかもしれません。(それは、まして効率的な帯域幅用法につながります)。
Note that scheduling of L1VPN services requires time-scoped resource management, which is not well considered in current GMPLS protocols and requires the support of the management plane. In addition, offering scheduling service and on-demand service on the same infrastructure needs careful consideration.
L1VPNサービスのスケジューリングが時間で見られた資源管理を必要とすることに注意してください。(資源管理は、現在のGMPLSプロトコルでよく考えられないで、管理飛行機のサポートを必要とします)。 さらに、同じインフラストラクチャに対してはスケジューリングサービスとオンデマンドサービスを提供すると、熟慮は必要とします。
Takeda Informational [Page 13] RFC 4847 Layer 1 VPN Framework April 2007
[13ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
5. Reference Model
5. 規範モデル
Figure 5.1 describes the L1VPN reference model.
図5.1はL1VPN規範モデルについて説明します。
: +--------------------+ :
: | +------------+ | :
: | | Management | | :
+------+ : | | system(s) | | : +------+
| C | : | +------------+ | : | CE | +------+
|device| : | | : |device|--| C |
+------+ : | +------+ : | of | |device|
| : | | |=:=|VPN A| +------+
| : | | | : +------+
+------+ : | | PE | : +------+
+------+ | CE | : | |device| : | CE | +------+
| C | |device| : +------+ +------+ | | : |device| | C |
|device|--| of |=:=| |==| |==| |-:-| of |--|device|
+------+ |VPN A| : | | | | +------+ : |VPN B| +------+
+------+ : | PE | | P | | : +------+
+------+ : |device| |device| | : +------+
+------+ | CE | : | | | | +------+ : | CE | +------+
| C |--|device|=:=| |==| |==| |-:-|device|--| C |
|device| | of | : +------+ +------+ | | : | of | |device|
+------+ |VPN B| : | | PE | : |VPN A| +------+
+------+ : | |device| : +------+
| : | | | : +------+
| : | | |=:=| CE | +------+
+------+ : | +------+ : |device| | C |
| C | : | | : | of |--|device|
|device| : | | : |VPN B| +------+
+------+ : | | : +------+
: | | :
Customer | | Customer
interface | | interface
+--------------------+
|<---- Provider ---->|
| network |
: +--------------------+ : : | +------------+ | : : | | 管理| | : +------+ : | | システム| | : +------+ | C| : | +------------+ | : | Ce| +------+ |デバイス| : | | : |デバイス|--| C| +------+ : | +------+ : | of| |デバイス| | : | | |=:=|VPN A| +------+ | : | | | : +------+ +------+ : | | PE| : +------+ +------+ | Ce| : | |デバイス| : | Ce| +------+ | C| |デバイス| : +------+ +------+ | | : |デバイス| | C| |デバイス|--| of|=:=| |==| |==| |-:-| of|--|デバイス| +------+ |VPN A| : | | | | +------+ : |VPN B| +------+ +------+ : | PE| | P| | : +------+ +------+ : |デバイス| |デバイス| | : +------+ +------+ | Ce| : | | | | +------+ : | Ce| +------+ | C|--|デバイス|=:=| |==| |==| |-:-|デバイス|--| C| |デバイス| | of| : +------+ +------+ | | : | of| |デバイス| +------+ |VPN B| : | | PE| : |VPN A| +------+ +------+ : | |デバイス| : +------+ | : | | | : +------+ | : | | |=:=| Ce| +------+ +------+ : | +------+ : |デバイス| | C| | C| : | | : | of|--|デバイス| |デバイス| : | | : |VPN B| +------+ +------+ : | | : +------+ : | | : 顧客| | 顧客インタフェース| | インタフェース+--------------------+ | <、-、-、-- プロバイダー---->|、| ネットワーク|
Key: ==== Layer 1 Connection -- link
キー: ==== 層1のConnection--リンクしてください。
Figure 5.1: L1VPN Reference Model
図5.1: L1VPN規範モデル
In an L1VPN, layer 1 connections are provided between CEs' data plane interfaces within the same VPN. In Figure 5.1, a connection is provided between the left-hand CE of VPN A and the upper right-hand CE of VPN A, and another connection is provided between the left-hand CE of VPN B and lower right-hand CE of VPN B (shown as "=" mark). These layer 1 connections are called VPN connections.
L1VPNでは、同じVPNの中のCEsのデータ飛行機インタフェースの間に層1の接続を提供します。 図5.1では、VPN Aの左手のCEとVPN Aの右上の手のCEの間に接続を提供します、そして、VPN Bの左手のCEとVPN Bの右下CE(「=」マークとして、目立つ)の間に別の接続を提供します。 これらの層1の接続はVPN接続と呼ばれます。
Takeda Informational [Page 14] RFC 4847 Layer 1 VPN Framework April 2007
[14ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
Note that as mentioned in Section 3.1, these VPN connections follow the hierarchy defined in [RFC4206].
これらのVPN接続がセクション3.1で言及されるように[RFC4206]で定義された階層構造に従うことに注意してください。
5.1. Management Systems
5.1. マネージメントシステム
As shown in the reference model, a provider network may contain one or more management systems. A management system may support functions including provisioning, monitoring, billing, and recording. Provider management systems may also communicate with customer management systems in order to provide services. Sections 7 and 11 provide more detail.
規範モデルで示されるように、プロバイダーネットワークは1台以上のマネージメントシステムを含むかもしれません。マネージメントシステムは食糧を供給していて、モニターしている支払い、および録音を含む機能をサポートするかもしれません。 また、プロバイダーマネージメントシステムは、サービスを提供するために顧客管理システムとコミュニケートするかもしれません。 セクション7と11はその他の詳細を提供します。
6. Generic Service Description
6. ジェネリックサービス記述
This section describes generic L1VPN services. Detailed descriptions are provided through specific service models in Section 7.
このセクションはジェネリックL1VPNサービスについて説明します。 セクション7の特定のサービスモデルを通して詳述を提供します。
6.1. CE Construct
6.1. Ce構造物
- The CE device may support more than one customer VPN.
- CEデバイスは、1人以上の顧客がVPNであるとサポートするかもしれません。
- CE-PE data plane links (between data plane interfaces) may be
shared by multiple VPNs.
- CE-PEデータ飛行機リンク(データ飛行機インタフェースの間の)は複数のVPNsによって共有されるかもしれません。
Note that it is necessary to disambiguate control plane messages exchanged between CE and PE if the CE-PE relationship is applicable to more than one VPN. This makes it possible to determine to which VPN such control plane messages apply. Such disambiguation might be achieved by allocating a separate control channel to each VPN (either using a separate physical channel, a separate logical channel such as IP tunnel, or using separate addressing).
CE-PE関係が1VPNに適切であるならCEとPEの間で交換されたコントロール飛行機メッセージのあいまいさを除くのが必要であることに注意してください。 これで、そのようなコントロール飛行機メッセージがどのVPNに適用されるかを決定するのが可能になります。 そのような曖昧さの解消は、別々の制御チャンネルを各VPNに割り当てることによって、達成されるかもしれません(別々の物理的なチャンネル、IPトンネルなどの別々の論理チャネルを使用するか、または別々のアドレシングを使用して)。
A customer addressing realm consists of CE-PE TE link addresses and CE-PE control channel addresses as well as customer site addresses (C and CE addresses). Customer addressing realms may overlap, and may also overlap with the service provider addressing realm.
顧客アドレシング分野は顧客サイトアドレス(CとCEアドレス)と同様にCE-PE TEリンクアドレスとCE-PE規制チャンネル・アドレスから成ります。 顧客アドレシング分野は、重なって、また、サービスプロバイダーアドレシング分野に重なるかもしれません。
NATs or firewalls might reasonably be placed at customer interfaces, or between administrative domains within the core network. Addressing in the L1VPN model must handle such eventualities. Traversal of NATs and firewalls within the customer network might have implications for L1VPN services that connect C devices, and is for further study.
NATsかファイアウォールが合理的に顧客インタフェースにおいて、または、コアネットワークの中の管理ドメインの間に置かれるかもしれません。 L1VPNモデルのアドレシングはそのような不測の事態を扱わなければなりません。 顧客ネットワークの中のNATsとファイアウォールの縦断は、Cデバイスを接続するL1VPNサービスのために意味を持っているかもしれなくて、さらなる研究にはあります。
Takeda Informational [Page 15] RFC 4847 Layer 1 VPN Framework April 2007
[15ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
6.2. Generic Service Features
6.2. ジェネリックサービス機能
L1VPN has the following two generic service features.
L1VPNには、以下の2つのジェネリックサービス機能があります。
- Connectivity restriction: Layer 1 connectivity is provided to a
limited set of CEs' data plane interfaces, called VPN end points.
(This set forms the L1VPN membership.)
- 接続性制限: VPNエンドポイントと呼ばれる限られたセットのCEsのデータ飛行機インタフェースに層1の接続性を提供します。 (このセットはL1VPN会員資格を形成します。)
- Per VPN control and management: Some level of control and
management capability is provided to the customer. Details differ
depending on service models described in Section 7.
- VPNコントロールと管理単位で: 何らかの管理水準と管理能力を顧客に提供します。 セクション7で説明されたサービスモデルに頼っていて、詳細は異なります。
7. Service Models
7. サービスモデル
This section describes Layer 1 VPN service models that can be supported by GMPLS protocols enabled networks. These models are derived from the generic service description presented above.
このセクションはGMPLSによってサポートされて、プロトコルがネットワークを可能にしたということであるかもしれないLayer1VPNサービスモデルについて説明します。 上に提示されたジェネリックサービス記述からこれらのモデルを得ます。
Such layer 1 networks are managed and controlled using GMPLS signaling as described in [RFC3471] and [RFC3473], and GMPLS routing as described in [RFC4202]. It must be understood that meeting the requirements set out in this document may necessitate extensions to the existing GMPLS protocols both for the control plane within the layer 1 network and for service provisioning at the edge of the network (CE and PE devices). A CE and a PE are connected by one or more data links. The ends of each link are usually represented as GMPLS-capable interfaces.
そのような層1のネットワークは、[RFC4202]で説明されるように[RFC3471]、[RFC3473]、およびGMPLSルーティングで説明されるように合図するGMPLSを使用することで経営されて、制御されます。 出された必要条件を満たすと拡大が本書では層1のネットワークの中の制御飛行機とネットワークの縁で(CEとPEデバイス)に食糧を供給するサービスのための既存のGMPLSプロトコルに必要とするかもしれないのを理解しなければなりません。 CEとPEは1個以上のデータ・リンクによって接続されます。 通常、それぞれのリンクの端はGMPLSできるインタフェースとして表されます。
Note that in this document, service models are classified by the semantics of information exchanged over the customer interface. The customer interface may be instantiated by the CE-PE control plane communication and/or the management plane communication between the customer management systems(s) and the provider management system(s). Note that how to realize a CE-PE control channel is discussed in Section 10.1. Customer management system(s) and provider management systems(s) may communicate by utilizing the CE-PE control channel(s).
本書では、サービスモデルが顧客インタフェースの上と交換された情報の意味論によって分類されることに注意してください。 顧客インタフェースは顧客管理システムとプロバイダーマネージメントシステムとのCE-PEコントロール飛行機コミュニケーション、そして/または、管理飛行機コミュニケーションによって例示されるかもしれません。 セクション10.1でどうCE-PE制御チャンネルがわかるかについて議論することに注意してください。 顧客管理システムとプロバイダーマネージメントシステムは、CE-PE制御チャンネルを利用することによって、交信するかもしれません。
Takeda Informational [Page 16] RFC 4847 Layer 1 VPN Framework April 2007
[16ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
7.1. Management-Based Service Model
7.1. 管理ベースのサービスモデル
Figure 7.1 describes the Management-based service model.
図7.1はManagementベースのサービスモデルについて説明します。
+--------------------+
: | |
+----------+ : | +----------+ |
| Customer | : | | Provider | |
|Management| : | |Management| |
| system(s)|-:-----+----| system(s)| |
+----------+ : | +----------+ |
: | | :
: | | :
+----+ : +----+ +----+ +----+ : +----+
| CE |----:---| PE |----| P |----| PE |---:---| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
+--------------------+ : | | +----------+ : | +----------+ | | 顧客| : | | プロバイダー| | |管理| : | |管理| | | システム|-:-----+----| システム| | +----------+ : | +----------+ | : | | : : | | : +----+ : +----+ +----+ +----+ : +----+ | Ce|----:---| PE|----| P|----| PE|---:---| Ce| +----+ : +----+ +----+ +----+ : +----+ : | | : : | | : : +--------------------+ : : | | : : | <、-プロバイダーネットワーク>| : 顧客Customerインタフェースインタフェース
Figure 7.1: Management-Based Service Model
図7.1: 管理ベースのサービスモデル
In this service model, customer management systems and provider management systems communicate with each other. Customer management systems access provider management systems to request layer 1 connection setup/deletion between a pair of CEs. Customer management systems may obtain additional information, such as resource availability information and monitoring information, from provider management systems. There is no control message exchange between a CE and PE.
このサービスモデルで、顧客管理システムとプロバイダーマネージメントシステムは互いにコミュニケートします。 要求する顧客管理システムアクセスプロバイダマネージメントシステムは1組のCEsの間の1つの接続設定/削除を層にします。 顧客管理システムは追加情報を得るかもしれません、リソース有用性情報や監視情報のように、プロバイダーマネージメントシステムから。CEとPEの間には、コントロール交換処理が全くありません。
The provider network may be based on GMPLS. In this case, mechanisms to support soft permanent connections can be applied. However, interfaces between management systems are not within the scope of this document.
プロバイダーネットワークはGMPLSに基づくかもしれません。 この場合、優しい永久接続をサポートするメカニズムを適用できます。 しかしながら、このドキュメントの範囲の中にマネージメントシステムの間のインタフェースがありません。
7.2. Signaling-Based Service Model (Basic Mode)
7.2. シグナリングベースのサービスモデル(基本のモード)
In this service model, the CE-PE interface's functional repertoire is limited to path setup signaling only. The provider's network is not involved in distribution of customer network's routing information.
このサービスモデルでは、CE-PEインタフェースの機能的なレパートリーは経路セットアップシグナリングだけに制限されます。 プロバイダーのネットワークは顧客ネットワークのルーティング情報の分配にかかわりません。
Takeda Informational [Page 17] RFC 4847 Layer 1 VPN Framework April 2007
[17ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
Note in addition that there may be communication between customer management system(s) and provider management system(s) in order to provide customers with detailed monitoring, fault information, etc.
顧客管理システムとプロバイダーマネージメントシステムとのコミュニケーションが詳細なモニター、欠点情報などを顧客に提供するためにあるかもしれないことにさらに、注意してください。
7.2.1. Overlay Service Model
7.2.1. オーバレイサービスモデル
Figure 7.2 describes the Overlay service model.
図7.2はOverlayサービスモデルについて説明します。
+--------------------+
: | | :
: | | :
+----+ : +----+ +----+ : +----+
| CE |---:---| PE | | PE |---:---| CE |
+----+ : +----+ +----+ : +----+
: | | :
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
+--------------------+ : | | : : | | : +----+ : +----+ +----+ : +----+ | Ce|---:---| PE| | PE|---:---| Ce| +----+ : +----+ +----+ : +----+ : | | : : | | : : +--------------------+ : : | | : : | <、-プロバイダーネットワーク>| : 顧客Customerインタフェースインタフェース
Figure 7.2: Overlay Service Model
図7.2: オーバレイサービスモデル
In this service model, the customer interface is based on the GMPLS UNI Overlay [RFC4208]. The CE requests layer 1 connection setup/deletion to a remote CE. There is no routing protocol running (i.e., no routing neighbor/peering relationship) between a CE and a PE. The CE does not receive routing information from remote customer sites, nor routing information about the provider network.
このサービスモデルでは、顧客インタフェースはGMPLS UNI Overlay[RFC4208]に基づいています。 CE要求は1つの接続設定/削除をリモートCEに層にします。 CEとPEとの(すなわち、ルーティングの隣人/じっと見る関係がありません)を実行するルーティング・プロトコルが全くありません。 CEは遠く離れた顧客サイトからのルーティング情報、およびプロバイダーネットワークのルーティング情報を受け取りません。
The CE's interface may be assigned a public or private address, that designates VPN end points.
公共の、または、個人的なアドレスはCEのインタフェースに割り当てられるかもしれなくて、それはVPNエンドポイントを指定します。
In this model, membership information needs to be configured on PEs, so that the PE that receives a Path message from the ingress CE can identify the remote PE connected to the egress CE. Distribution of membership information between PEs is typically done by the provider, and may be realized by mechanisms such as static provisioning, or by piggybacking on routing protocols (auto-discovery).
このモデルでは、会員資格情報は、PEsで構成される必要があります、イングレスCEからPathメッセージを受け取るPEが出口CEに接続されたリモートPEを特定できるように。 PEsの間の会員資格情報の分配をプロバイダーで通常して、静的な食糧を供給することなどのメカニズム、またはルーティング・プロトコル(自動発見)で便乗することによって、実現するかもしれません。
There are various ways that customers perceive the provider network. In one example, the whole provider network may be considered as one node -- the path specified and recorded in signaling messages reflects this. Note that this is distinct from the Virtual Node service model described in Section 7.3.2 because such a model requires that the network is represented to the VPN sites as a virtual node -- that is, some form of routing advertisement is
顧客が、プロバイダーがネットワークでつなぐと知覚する様々な道があります。 1つの例では、全体のプロバイダーネットワークは1つのノードであるとみなされるかもしれません--指定されてシグナリングメッセージに記録された経路はこれを反映します。 これがそのようなモデルが、ネットワークが仮想ノードとしてVPNサイトに代表されるのを必要とするのでセクション7.3.2で説明されたVirtual Nodeサービスモデルと異なっていることに注意してください--すなわち何らかの形式のルーティング広告はそうです。
Takeda Informational [Page 18] RFC 4847 Layer 1 VPN Framework April 2007
[18ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
implied, and this is not in scope for the Signaling-based service model.
暗示、これはSignalingベースのサービスモデルのための範囲にありません。
7.3. Signaling and Routing Service Model (Enhanced Mode)
7.3. シグナリングとルート設定サービスはモデル化されます。(高められたモード)
In this service model, the CE-PE interface provides the signaling capabilities as in the Basic Mode, plus permits limited exchange of information between the control planes of the provider and the customer to help such functions as discovery of customer network routing information (i.e., reachability or TE information in remote customer sites), or parameters of the part of the provider's network dedicated to the customer.
このサービスモデルでは、CE-PEインタフェースは、Basic Modeのようにシグナリング能力を前提として、プロバイダーと顧客の制御飛行機の間の限られた情報交換が顧客ネットワークルーティング情報(遠く離れた顧客サイトのすなわち、可到達性かTE情報)の発見、または顧客に捧げられたプロバイダーのネットワークの部分のパラメタのような機能を助けることを許可します。
By allowing CEs to obtain customer network routing information, a so-called N-square routing problem could be solved.
CEsが顧客ネットワークルーティング情報を得るのを許容することによって、いわゆるN-正方形ルーティング問題を解決できるでしょう。
In addition, by using the received traffic engineering-based routing information, a customer can use traffic engineering capabilities. For example, a customer can set up two disjoint connections between a pair of CEs. Another example is that a customer can request a connection between a pair of devices within customer sites, and not necessarily between CEs, with more effective traffic engineering.
さらに、受信されたトラフィック工学ベースのルーティング情報を使用することによって、顧客は交通工学能力を使用できます。 例えば、2に設定された顧客缶は1組のCEsの間の接続をばらばらにならせます。 別の例は顧客がCEsの間で必ずではなく顧客サイトの中の1組のデバイスの間の接続を要求できるということです、より効果的な交通工学で。
As such, the customer interface is based on GMPLS signaling and mechanisms to exchange reachability/TE information. Typically, a routing protocol is used between a CE and PE, or more precisely between a CE and the VPN routing context instantiated on the PE. Link state routing information would be needed to implement the above two example scenarios. Some scenarios may be satisfied with reachability routing information only.
そういうものとして、顧客インタフェースは、可到達性/TE情報を交換するためにGMPLSシグナリングとメカニズムに基づいています。 通常、ルーティング・プロトコルはCEとPEの間かPEに例示されたCEとVPNルーティング文脈の間で、より正確に使用されます。 リンク州のルーティング情報が、上記の2の例がシナリオであると実装するのに必要でしょう。 いくつかのシナリオが可到達性ルーティング情報だけに満たされるかもしれません。
Note that this service model does not preclude the use of mechanisms other than routing protocols to exchange reachability/TE information.
このサービスモデルが可到達性/TE情報を交換するためにルーティング・プロトコル以外のメカニズムの使用を排除しないことに注意してください。
As with the Signaling-based service model, there may be communication between customer management system(s) and provider management system(s) in order to provide detailed monitoring, fault information etc. to customers.
Signalingベースのサービスモデルなら、顧客管理システムとプロバイダーマネージメントシステムとのコミュニケーションが、情報の詳細な欠点モニターなどを顧客に提供するためにあるかもしれません。
Four specific types of the Signaling and Routing service model are the Overlay Extension service model, the Virtual Node service model, the Virtual Link service model and the Per-VPN Peer service model, depending on how customers perceive the provider network in routing and signaling (i.e., the level of information details that a customer is allowed to receive in routing and signaling).
Signalingとルート設定サービスモデルの4人の特定のタイプがOverlay Extensionサービスモデルです、Virtual Nodeサービスモデル、Virtual LinkサービスモデルとPer-VPN Peerサービスモデル、顧客が、ルーティングとシグナリングにおけるプロバイダーネットワークが(すなわち、顧客がルーティングとシグナリングで受信できるという情報の詳細のレベル)であるとどう知覚するかによって。
Takeda Informational [Page 19] RFC 4847 Layer 1 VPN Framework April 2007
[19ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
7.3.1. Overlay Extension Service Model
7.3.1. オーバレイ館外活動モデル
This service model complements the Overlay service model. In this service model, a CE receives a list of CE-PE TE link addresses to which it can request a VPN connection (i.e., membership information). This may include additional information concerning these TE links (e.g., switching type). Mechanisms other than routing could be used to exchange reachability/TE information between the CE and the PE.
このサービスモデルはOverlayサービスモデルの補足となります。 このサービスモデルで、CEはそれがVPN接続(すなわち、会員資格情報)を要求できるCE-PE TEリンクアドレスのリストを受け取ります。 これはこれらのTEリンク(例えば、切り換えタイプ)に関して追加情報を含むかもしれません。 CEとPEの間で可到達性/TE情報を交換するのにルーティング以外のメカニズムを使用できました。
7.3.2. Virtual Node Service Model
7.3.2. 仮想ノードサービスモデル
Figure 7.3 describes the Virtual Node service model.
図7.3はVirtual Nodeサービスモデルについて説明します。
+--------------------+
: | | :
+----+ : | | : +----+
| CE |---:---| Virtual Node |---:---| CE |
+----+ : | | : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
+--------------------+ : | | : +----+ : | | : +----+ | Ce|---:---| 仮想ノード|---:---| Ce| +----+ : | | : +----+ : | | : : +--------------------+ : : | | : : | <、-プロバイダーネットワーク>| : 顧客Customerインタフェースインタフェース
Figure 7.3: Virtual Node Service Model
図7.3: 仮想ノードサービスモデル
In this type of service model, the whole provider network is represented as a virtual node (defined in Section 2). The customer perceives the provider network as one single node. The CE receives routing information about CE-PE links and the customer network (i.e., remote customer sites).
このタイプのサービスモデルで、全体のプロバイダーネットワークは仮想ノード(セクション2では、定義される)として代表されます。 顧客は、1つのただ一つのノードとしてプロバイダーがネットワークであると知覚します。 CEはCE-PEリンクと顧客ネットワーク(すなわち、遠く離れた顧客サイト)のルーティング情報を受け取ります。
Note that in this service model, there must be one single virtual node, and this virtual node must be connected with every CE in the VPN.
このサービスモデルには、1つのただ一つの仮想ノードがあるに違いなくて、VPNのあらゆるCEにこの仮想ノードを接続しなければならないことに注意してください。
Takeda Informational [Page 20] RFC 4847 Layer 1 VPN Framework April 2007
[20ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
7.3.3. Virtual Link Service Model
7.3.3. 事実上のリンクサービスモデル
Figure 7.4 describes the Virtual Link service model.
図7.4はVirtual Linkサービスモデルについて説明します。
+--------------------+
: | | :
: | Virtual | :
+----+ : +----+ link +----+ : +----+
| CE |---:---| PE |**************| PE |---:---| CE |
+----+ : +----+ +----+ : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
+--------------------+ : | | : : | 仮想| : +----+ : +----+ リンク+----+ : +----+ | Ce|---:---| PE|**************| PE|---:---| Ce| +----+ : +----+ +----+ : +----+ : | | : : +--------------------+ : : | | : : | <、-プロバイダーネットワーク>| : 顧客Customerインタフェースインタフェース
Figure 7.4: Virtual Link Service Model
図7.4: 事実上のリンクサービスモデル
In this service model, a virtual link is constructed between PEs. For the definition of a virtual link, please refer to terminology in Section 2. A virtual link is assigned to each VPN and disclosed to the corresponding CEs. As such, the CE receives routing information about CE-PE links, customer network (i.e., remote customer sites), as well as virtual links assigned to each VPN. A special property of the virtual links used in this service model is that the provider network allocates data plane link resources for the exclusive use of each virtual link. The TE attributes of a virtual link are determined according to data plane link resources allocated to this virtual link. Virtual links are an abstraction of the provider network to customers for administrative purposes as well as to exclude "unnecessary information".
このサービスモデルでは、仮想のリンクはPEsの間で組み立てられます。 仮想のリンクの定義について、セクション2の用語を参照してください。 仮想のリンクは、各VPNに割り当てられて、対応するCEsに明らかにされます。 そういうものとして、CEはCE-PEリンクのルーティング情報を受け取ります、顧客ネットワーク(すなわち、遠く離れた顧客サイト)、各VPNに割り当てられた仮想のリンクと同様に。 このサービスモデルで使用される仮想のリンクの特別な性質はプロバイダーネットワークがそれぞれの仮想のリンクの専用のためのデータ飛行機リンクリソースを割り当てるということです。 この仮想のリンクに割り当てられたデータ飛行機リンクリソースによると、仮想のリンクのTE属性は決定しています。 仮想のリンクはまた、管理目的のための顧客への「不要な情報」を除くほどプロバイダーネットワークの抽象化です。
Note that in this service model, both end points of each virtual link must be a PE device.
それぞれの仮想のリンクの両端点がこのサービスモデルでは、PEデバイスであるに違いないことに注意してください。
Takeda Informational [Page 21] RFC 4847 Layer 1 VPN Framework April 2007
[21ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
7.3.4. Per-VPN Peer Service Model
7.3.4. 1VPNあたりの同輩サービスモデル
Figure 7.5 describes the Per-VPN Peer service model.
図7.5はPer-VPN Peerサービスモデルについて説明します。
+--------------------+
: | | :
+----+ : +----+ +----+ +----+ : +----+
| CE |---:---| PE |----| P |----| PE |---:---| CE |
+----+ : +----+ +----+ +----+ : +----+
: | | :
: +--------------------+ :
: | | :
: |<-Provider network->| :
Customer Customer
interface interface
+--------------------+ : | | : +----+ : +----+ +----+ +----+ : +----+ | Ce|---:---| PE|----| P|----| PE|---:---| Ce| +----+ : +----+ +----+ +----+ : +----+ : | | : : +--------------------+ : : | | : : | <、-プロバイダーネットワーク>| : 顧客Customerインタフェースインタフェース
Figure 7.5: Per-VPN Peer Service Model
図7.5: 1VPNあたりの同輩サービスモデル
This service model is a generalization and combination of the Virtual Link service model and the Virtual Node service model mentioned in Sections 7.3.2 and 7.3.3 respectively.
このサービスモデルは一般化です、そして、Virtual LinkサービスモデルとVirtual Nodeサービスモデルの組み合わせはセクション7.3.2と7.3でそれぞれ.3について言及しました。
In this service model, the provider partitions the TE links within the provider network per VPN, and discloses per-VPN TE link information to corresponding CEs. As such, a CE receives routing information about CE-PE links, customer network (i.e., remote customer sites), as well as partitioned portions of the provider network.
このサービスモデル、プロバイダーパーティションにおけるTEは1VPNあたりのプロバイダーネットワークの中でリンクして、1VPN TEあたりのリンク情報を対応するCEsに明らかにします。 そういうものとして、CEはCE-PEリンクのルーティング情報を受け取ります、顧客ネットワーク(すなわち、遠く離れた顧客サイト)、プロバイダーネットワークの仕切られた部分と同様に。
Note that PEs may advertise abstracted routing information about the provider network to CEs for administrative purpose as well as to exclude "unnecessary information". In other words, virtual links may be constructed between two nodes where direct data links do not exist, or virtual nodes may be constructed to represent multiple physical nodes and links between them.
PEsが管理目的、「不要な情報」を除くためにプロバイダーネットワークの放心しているルーティング情報のCEsに広告を出すかもしれないことに注意してください。 言い換えれば、仮想のリンクがダイレクトデータ・リンクが存在しない2つのノードの間で組み立てられるかもしれませんか、または仮想ノードは、それらの間の複数の物理的なノードとリンクを表すために構成されるかもしれません。
In the Per-VPN Peer service model, at least one virtual node corresponding to P devices (one single P or a set of Ps) must be visible to customers.
Per-VPN Peerサービスモデルでは、顧客にとって、Pデバイス(1つのシングルPかPsのセット)に対応する少なくとも1つの仮想ノードが目に見えるに違いありません。
8. Service Models and Service Requirements
8. サービスモデルとサービス要件
The service models mentioned in Section 7 are related to what information is exchanged between CE and PE. In addition, service models differ in how data plane resources are allocated for each VPN.
セクション7で言及されたサービスモデルはCEとPEの間でどんな情報を交換するかと関係づけられます。 さらに、サービスモデルは各VPNのためにどうデータ飛行機リソースを割り当てるかに異なります。
Note that in the ITU-T documents, the term "U-Plane" is used instead of "data plane".
ITU-Tドキュメントでは、「U-飛行機」という用語が「データ飛行機」の代わりに使用されることに注意してください。
Takeda Informational [Page 22] RFC 4847 Layer 1 VPN Framework April 2007
[22ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
o Data plane resource allocation
o データ飛行機資源配分
- Shared or dedicated:
- 共有されるかひたむき:
Shared means that provider network data plane links are shared by
multiple (i.e., any or a specific set of) VPNs. (Data plane
links are dynamically allocated to a VPN when a VPN connection is
requested, and data plane links allocated to one VPN at one time
can be allocated to another VPN at another time.)
プロバイダーネットワークデータ飛行機が結ぶ共有された手段は複数の(すなわち、いずれかセットされた詳細)VPNsによって共有されます。 (VPN接続を要求するとき、ダイナミックにデータ飛行機リンクをVPNに割り当てて、別の時にひところ1VPNに割り当てられたデータ飛行機リンクは別のVPNに割り当てることができます。)
Dedicated means that provider network data plane links are
partitioned per VPN. (Data plane links are statically allocated
to one VPN and can not be used by other VPNs.)
プロバイダーネットワークデータ飛行機が結ぶひたむきな手段はVPN単位で仕切られます。 (データ飛行機リンクを静的に1VPNに割り当てて、他のVPNsは使用できません。)
o Information exchanged between CE and PE
o CEとPEの間で交換された情報
- Signaling
- シグナリング
- Membership information (optionally includes TE information of the
associated CE-PE TE links)
- 会員資格情報(任意に、関連CE-PE TEリンクのTE情報を含んでいます)
- Customer network routing information (reachability only, or may
include TE information)
- 顧客ネットワークルーティング情報(可到達性だけ、TE情報を含むかもしれない、)
- Provider network routing information (TE information)
- プロバイダーネットワークルーティング情報(TE情報)
Note that link management information (e.g., LMP [RFC4204]) may be
exchanged between a CE and a PE, but this is orthogonal to the
definition of the service models.
CEとPEの間でリンク経営情報(例えば、LMP[RFC4204])を交換するかもしれませんが、これがサービスモデルの定義と直交していることに注意してください。
Table 1 shows combination of service requirements and service
models.
テーブル1はサービス要件とサービスモデルの組み合わせを示しています。
Takeda Informational [Page 23] RFC 4847 Layer 1 VPN Framework April 2007
[23ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
| Data plane | Data plane
| shared | dedicated
---------------------------+------------------+-------------------
Signaling | Overlay | Overlay
---------------------------+------------------+-------------------
Signaling + | Overlay | Overlay
Membership information | Extension | Extension
---------------------------+------------------+-------------------
Signaling + | |
Membership information + | Virtual Node | Virtual Node
Customer network routing | |
information | |
---------------------------+------------------+-------------------
Signaling + | |
Membership information + | | Virtual Link
Customer network routing | Not applicable |
information + | | Per-VPN Peer
Provider network routing | |
information | |
| データ飛行機| データ飛行機| 共有されます。| 捧げられます。---------------------------+------------------+------------------- シグナリング| オーバレイ| オーバレイ---------------------------+------------------+------------------- シグナリング+| オーバレイ| オーバレイMembership情報| 拡大| 拡大---------------------------+------------------+------------------- シグナリング+| | 会員資格情報+| 仮想ノード| 仮想のNode Customerネットワークルーティング| | 情報| | ---------------------------+------------------+------------------- シグナリング+| | 会員資格情報+| | 仮想のLink Customerネットワークルーティング| 適切でない| 情報+| | 1VPN Peer Providerあたりのネットワークルーティング| | 情報| |
Table 1: Combination of service requirements and service models
テーブル1: サービス要件とサービスモデルの組み合わせ
As described in previous sections, the difference between the Virtual Link service model and the Per-VPN Peer service model is whether customers have visibility of P devices. In the Virtual Link service model, the end points of virtual links must be PE devices, thus P devices are not visible to customers. In the Per-VPN Peer service model, at least one virtual node corresponding to P devices (one single P, or a set of Ps) is visible to customers.
前項で説明されるように、Virtual LinkサービスモデルとPer-VPN Peerサービスモデルの違いは顧客にはPデバイスの目に見えることがあるかどうかということです。 仮想のリンクのエンドポイントがVirtual Linkサービスモデルでは、PEデバイスであるに違いない、その結果、顧客にとって、Pデバイスは目に見えません。 Per-VPN Peerサービスモデルでは、顧客にとって、Pデバイス(1つのシングルP、またはPsの1セット)に対応する少なくとも1つの仮想ノードが目に見えます。
Note that when customers receive provider network routing information in the form of virtual link, customers must be able to specify such links for a VPN connection over the provider network in signaling.
顧客が仮想のリンクの形にプロバイダーネットワークルーティング情報を受け取るとき、顧客がシグナリングでプロバイダーネットワークの上のVPN接続にそのようなリンクを指定できなければならないことに注意してください。
8.1. Detailed Service Level Requirements
8.1. 詳細なサービスレベル要件
In addition to the requirements set out in table 1, more detailed service requirements are provided below. They are generally common to the various service models, except where indicated.
テーブル1を始められた要件に加えて、より詳細なサービス要件を以下に提供します。 一般に、示されるのを除いて、様々なサービスモデルに、それらは一般的です。
- Selection of layer 1 service class: Customers MAY be allowed to
specify a layer 1 service class (e.g., availability level) for a
VPN connection. Further details are described in Section 9.
- 層1のサービスのクラスの選択: 顧客は層の1つのサービスのクラス(例えば、有用性レベル)をVPN接続に指定できるかもしれません。 詳細はセクション9で説明されます。
Takeda Informational [Page 24] RFC 4847 Layer 1 VPN Framework April 2007
[24ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
- Reception of performance information: Customers MAY be allowed to
receive performance information for their VPN connections (e.g.,
performance monitoring data). When data plane links are dedicated,
customers MAY be allowed to receive performance information for
links dedicated to them.
- 性能情報のレセプション: 顧客は彼らのVPN接続(例えば、性能のモニターしているデータ)のために性能情報を受け取ることができるかもしれません。 データ飛行機リンクが専用であるときに、顧客はそれらに捧げられたリンクのための性能情報を受け取ることができるかもしれません。
- Reception of fault information: Customers MAY be allowed to receive
fault information for their VPN connections (e.g., failure
notification by RSVP-TE, data plane alarm notification through the
management plane, notification of connection setup rejection
causes). Note that this does not prevent customers from using
Operations and Management (OAM) mechanisms for, or on, their VPN
connections. When data plane links are dedicated, customers MAY be
allowed to receive fault information for links dedicated to them.
- 欠点情報のレセプション: 顧客は彼らのVPN接続のために欠点情報を受け取ることができるかもしれません(例えば、RSVP-TEによる失敗通知、データ飛行機が管理飛行機を通した通知を驚かせます、接続設定拒絶原因の通知)。 これが、顧客が接続か彼らのVPN接続のときにOperationsとManagement(OAM)メカニズムを使用するのを防がないことに注意してください。 データ飛行機リンクが専用であるときに、顧客はそれらに捧げられたリンクのための欠点情報を受け取ることができるかもしれません。
- Reception of connection information: Customers MAY be allowed to
receive information for current VPN connections (through the
management plane).
- 接続情報のレセプション: 顧客は現在のVPN接続(管理飛行機を通した)のために情報を受け取ることができるかもしれません。
- Reception of accounting information: Customers MUST be able to
receive accounting information for each VPN.
- 課金情報のレセプション: 顧客は各VPNのために課金情報を受け取ることができなければなりません。
- Specification of policy: Customers MAY be allowed to specify
policies (e.g., path computation policies, recovery policies
including parameters) for each VPN.
- 方針の仕様: 顧客は方針(例えば、経路計算方針、パラメタを含む回復方針)を各VPNに指定できるかもしれません。
- Security: The communication between the customer and the provider
MUST be secure. Further details are described in Section 12.
- セキュリティ: 顧客とプロバイダーとのコミュニケーションは安全であるに違いありません。 詳細はセクション12で説明されます。
- Filtering: Unnecessary information (e.g., information concerning
other VPNs) MUST NOT be provided to each customer. This applies
particularly to the Signaling and Routing service model, but is
also relevant to the Signaling-based service model and to the
Management-based service model. Further details are described in
Section 12.
- フィルタリング: 不要な情報(例えば、他のVPNsの情報)を各顧客に提供してはいけません。 これも、特にSignalingとルート設定サービスモデルに適用しますが、また、Signalingベースのサービスモデルと、そして、Managementベースのサービスモデルに関連しています。 詳細はセクション12で説明されます。
9. Recovery Aspects
9. 回復局面
9.1. Recovery Scope
9.1. 回復範囲
GMPLS provides various recovery techniques for use in different recovery scenarios [RFC4427]. The provider network may apply these recovery techniques to protect VPN connections as part of the L1VPN service, for example as follows:
GMPLSは異なった回復シナリオ[RFC4427]における使用のための様々なリカバリ技術を提供します。 プロバイダーネットワークは例えば、以下の通りL1VPNサービスの一部としてVPN接続を保護するためにこれらのリカバリ技術を当てはまるかもしれません:
Takeda Informational [Page 25] RFC 4847 Layer 1 VPN Framework April 2007
[25ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
o PE-PE recovery
o PE-PE回復
The provider network constitutes a recovery domain, and the
recovery scope is the PE-PE part of the CE-CE VPN connection.
プロバイダーネットワークは回復ドメインを構成します、そして、回復範囲はCE-CE VPN接続のPE-PE部分です。
It should be possible for the provider network to hide the provider
network recovery operation from the customer. Namely, it should be
possible to configure the provider network to not notify the
customer when a failure occurs and a PE-PE recovery operation
successfully repairs the failure. Further, when PE-PE recovery
fails and the failure should be notified to the customer, it should
be possible for the provider network to hide its internal topology.
プロバイダーネットワークがプロバイダーネットワーク回復動作を顧客から隠すのは、可能であるべきです。 すなわち、失敗が起こって、PE-PE回復動作が首尾よく失敗を修理するとき、顧客に通知しないようにプロバイダーネットワークを構成するのは可能であるべきです。 PE-PE回復が失敗して、失敗が顧客に通知されるべきであるとき、さらに、プロバイダーネットワークが内部のトポロジーを隠すのは、可能であるべきです。
o CE-PE recovery
o CE-PE回復
The recovery scope is either or both of the ingress and egress
CE-PE links of the CE-CE VPN connection.
回復範囲は、イングレスのどちらかか両方とCE-CE VPN接続の出口のCE-PEリンクです。
o CE-CE recovery
o CE-CE回復
The recovery scope is the entire CE-CE VPN connection.
回復範囲は全体のCE-CE VPN接続です。
When a failure needs to be notified to a customer so that the
customer can initiate recovery operation, it should be possible for
the provider network to hide its internal topology.
失敗が、顧客が回復動作を開始できるように顧客に通知される必要があるとき、プロバイダーネットワークが内部のトポロジーを隠すのは、可能であるべきです。
These recovery schemes may be applied in combination.
これらの回復体系は組み合わせで適用されるかもしれません。
Customers may be allowed to specify the desired recovery level in a connection setup request. Furthermore, the customer may be allowed to specify the desired recovery level in a way that is agnostic of the recovery technique (e.g., when the recovery operation does not require cooperation between the provider network and the customer network). In such cases, the provider network must translate the specified recovery level into specific recovery techniques, based on operational policies. This allows enhanced recovery techniques above and beyond the GMPLS specifications to be used in the provider network.
顧客は接続設定要求における必要な回復レベルを指定できるかもしれません。 その上、顧客はリカバリ技術の不可知論者であることの方法で必要な回復レベルを指定できるかもしれません(例えば、回復動作はいつプロバイダーネットワークと顧客ネットワークとの協力を必要としませんか)。 そのような場合、プロバイダーネットワークは運用政策に基づいて指定された回復レベルを特定のリカバリ技術に翻訳しなければなりません。 これは、GMPLS仕様を超えた強制回収のテクニックがプロバイダーネットワークに使用されるのを許容します。
9.2. Recovery Resource Sharing Schemes
9.2. 回復リソース・シェアリング体系
The provider network may support various recovery resource sharing schemes, such as the following:
プロバイダーネットワークは以下などの様々な回復リソース・シェアリング体系をサポートするかもしれません:
o Shared recovery
o 共有された回復
When the provider network supports shared recovery (e.g., shared
mesh restoration [RFC4427]), the provider network may provide
プロバイダーネットワークが、プロバイダーネットワークが共有された回復(例えば、共有されたメッシュ回復[RFC4427])をサポートするのを前提とするかもしれないなら
Takeda Informational [Page 26] RFC 4847 Layer 1 VPN Framework April 2007
[26ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
sharing recovery resources between VPN connections that serve with
only the same VPN, a specific set of VPNs, or any VPN. The default
mode is sharing recovery resources with any VPN.
同じVPNだけと共に勤めるVPN接続、VPNsの特定のセット、またはどんなVPNの間の回復リソースを共有します。 デフォルトモードはどんなVPNとも回復リソースを共有することです。
o Extra traffic
o 付加的なトラフィック
GMPLS recovery mechanisms support extra traffic. Extra traffic
allows the transfer of preemptable traffic on the recovery
resources when these resources are not being used for the recovery
of protected normal traffic [RFC4427].
GMPLS回収機構は付加的なトラフィックをサポートします。 これらのリソースが保護された正常なトラフィック[RFC4427]の回復に使用されていないとき、付加的なトラフィックは回復リソースにおける先取り可能トラフィックの乗り換えを許します。
In the context of L1VPNs, extra traffic is applied for CE-CE VPN
connections, or PE-PE part of CE-CE VPN connections. The latter
case may be applied only when there is hierarchy (i.e., CE-CE VPN
connection is nested on top of PE-PE connection). In this section,
the latter aspect is analyzed.
L1VPNsの文脈では、付加的なトラフィックはCE-CE VPN接続、またはCE-CE VPN接続のPE-PE部分に適用されます。 階層構造があるときだけ(すなわち、CE-CE VPN接続はPE-PE接続の上で入れ子にされます)、後者のケースは適用されるかもしれません。 このセクションでは、後者の局面は分析されます。
When the provider network allows a CE-CE VPN connection to be set
up as "extra traffic", it means that the VPN connection may use a
PE-PE connection that protects some other CE-CE VPN connection. In
such a case the provider network may restrict extra traffic CE-CE
VPN connection to use resources (i.e., the PE-PE connections) that:
プロバイダーネットワークが、CE-CE VPN接続が「付加的なトラフィック」としてセットアップされるのを許容するとき、それは、VPN接続がある他のCE-CE VPN接続を保護するPE-PE接続を使用するかもしれないことを意味します。 このような場合にはプロバイダーネットワークがリソース(すなわち、PE-PE接続)を使用するために付加的なトラフィックCE-CE VPN接続を制限するかもしれない、それ:
- protect VPN connections from the same VPN as the extra traffic
connection.
- 付加的なトラフィック接続と同じVPNからVPN接続を保護してください。
- are used for a specific set of VPNs.
- VPNsの特定のセットのために、使用されます。
- are available for any VPN.
- どんなVPNにも、利用可能です。
The default mode is to support preemptable traffic on recovery resources reserved for any VPN.
デフォルトモードはどんなVPNのためにも予約された回復リソースで先取り可能トラフィックをサポートすることです。
10. Control Plane Connectivity
10. コントロール飛行機の接続性
10.1. Control Plane Connectivity between a CE and a PE
10.1. CeとPEの間のコントロール飛行機の接続性
In the Signaling-based service model and the Signaling and Routing service model, there must be a control channel (IP-level connectivity) between a CE and its PE. The instantiation of the control channel may differ depending on addressing and security.
Signalingベースのサービスモデル、Signaling、およびルート設定サービスモデルには、CEとそのPEの間には、制御チャンネル(IP-レベルの接続性)があるに違いありません。 アドレシングとセキュリティによって、制御チャンネルの具体化は異なるかもしれません。
As stated in Section 6.1, it is necessary to disambiguate control plane messages exchanged between the CE and PE if the CE-PE relationship is applicable to more than one VPN. Furthermore, private addresses may be assigned to CE-PE control channels.
セクション6.1に述べられているように、CE-PE関係が1VPNに適切であるならCEとPEの間で交換されたコントロール飛行機メッセージのあいまいさを除くのが必要です。 その上、プライベート・アドレスはCE-PE制御チャンネルに割り当てられるかもしれません。
Takeda Informational [Page 27] RFC 4847 Layer 1 VPN Framework April 2007
[27ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
Security aspects of the CE-PE control channel are discussed in Section 12.
セクション12でCE-PE制御チャンネルのセキュリティ局面について議論します。
10.2. Control Plane Connectivity between CEs
10.2. CEsの間のコントロール飛行機の接続性
A customer network connected by VPN connections may be controlled by MPLS or GMPLS, and the VPN connections may be treated as TE links within the customer network. In such cases, there must be control plane (IP-level) connectivity between the CEs, so that control messages, such as signaling and routing messages, can be exchanged between the CEs. Furthermore, in some recovery techniques, Notify message exchange is needed between the ingress and egress of the VPN connection, which requires control plane connectivity between the CEs. There are several potential ways to achieve this.
VPN接続によって接続された顧客ネットワークはMPLSかGMPLSによって制御されるかもしれません、そして、VPN接続は顧客ネットワークの中でTEリンクとして扱われるかもしれません。 そのような場合、CEsの間には、制御飛行機(IP-レベル)の接続性があるに違いありません、CEsの間でシグナリングやルーティング・メッセージなどのコントロールメッセージを交換できるように。 その上、いくつかのリカバリ技術で、Notify交換処理がVPN接続のイングレスと出口の間で必要です。出口はCEsの間のコントロール飛行機の接続性を必要とします。 これを達成するいくつかの潜在的方法があります。
o Use of VPN connections as in-band control channels
o バンドの制御チャンネルとしてのVPN接続の使用
If the CEs have the ability to inject control messages into the VPN
connections and to extract the messages at the far end of the VPN
connections, then control messages can be exchanged in-band. For
example, when a VPN connection is a Packet Switch Capable (PSC) TE
link in the customer network, this operation is transparent to the
L1VPN service provider.
CEsにVPN接続にコントロールメッセージを注いで、VPN接続の遠端でメッセージを抜粋する能力があるなら、バンドでコントロールメッセージを交換できます。 VPN接続がTEが顧客ネットワークでリンクするPacket Switch Capable(PSC)であるときに、例えば、この操作はL1VPNサービスプロバイダーにわかりやすいです。
o Use of overhead associated with the VPN connections
o VPN接続に関連しているオーバーヘッドの使用
If the VPN connection provides connectivity in the customer network
at a different switching capability (implying network technology
layer) from that used by the provider network to support the CE-PE
and PE-PE connectivity, then the customer network can utilize any
overhead available within the VPN connection as a control channel
to connect the CEs. For example, if a VPN connection provides a
TDM TE link in the customer network but is supported by a
technology such as lambda or fiber, then the CEs may utilize the
overhead (DCC) as a control channel, if the network supports
transparent transfer of such overhead. This operation is
transparent to the L1VPN service provider.
VPN接続がCE-PEとPE-PEの接続性をサポートするのにプロバイダーネットワークによって使用されたそれと異なったスイッチング能力(ネットワーク技術層を含意する)で顧客ネットワークに接続性を提供するなら、顧客ネットワークは、CEsを接続するのに制御チャンネルとしてVPN接続の中で利用可能などんなオーバーヘッドも利用できます。 例えば、VPN接続がTDM TEリンクを顧客ネットワークに提供しますが、λかファイバーなどの技術でサポートされるなら、CEsは制御チャンネルとしてオーバーヘッド(DCC)を利用するかもしれません、ネットワークがそのようなオーバーヘッドのわかりやすい転送をサポートするなら。 この操作はL1VPNサービスプロバイダーにわかりやすいです。
o Use of control-channel-specific VPN connections
o コントロールチャンネル詳細VPN接続の使用
A customer establishes VPN connections dedicated as control
channels. This operation is transparent to the L1VPN service
provider, but since control plane traffic is likely to be
relatively low compared with the capacity of VPN connections, this
may be an expensive solution for the customer.
顧客はコントロールがチャネルを開設するように専念したVPN接続を確立します。 この操作はL1VPNサービスプロバイダーにわかりやすいのですが、コントロール飛行機通行がVPN接続の容量と比べて比較的低い傾向があるので、これは顧客にとって、高価なソリューションであるかもしれません。
Takeda Informational [Page 28] RFC 4847 Layer 1 VPN Framework April 2007
[28ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
o Use of separate network
o 別々のネットワークの使用
A customer may utilize another network and network service, such as
private line service, L3VPN service, L2VPN service, or Internet
access service, to establish CE-CE control channel connectivity.
This operation is transparent to the L1VPN service provider.
顧客は、CE-CEコントロールチャンネルの接続性を証明するのに私設回線サービス、L3VPNサービス、L2VPNサービス、またはインターネット・アクセスサービスなどの別のネットワークとネットワーク・サービスを利用するかもしれません。 この操作はL1VPNサービスプロバイダーにわかりやすいです。
o Use of CE-PE control channels
o CE-PE制御チャンネルの使用
In the Signaling-based service model, and the Signaling and Routing
service model, there must be control plane (IP-level) connectivity
between the CE and PE, as described in Section 10.1.
Signalingベースのサービスモデル、Signaling、およびルート設定サービスモデルには、CEとPEの間には、制御飛行機(IP-レベル)の接続性があるに違いありません、セクション10.1で説明されるように。
By utilizing this, CE-CE control message exchange could be realized
as part of the service provided by the L1VPN service provider.
Namely, the provider network transfers control messages received
over the CE-PE control channel to the other side of the provider
network and delivers them through the PE-CE control channel. The
realization of this within the provider network is up to the
operator, but where the provider network uses a GMPLS control
plane, the customer control plane messages could be forwarded
through the provider control plane, perhaps using IP tunnels.
これを利用することによって、L1VPNサービスプロバイダーによって提供されたサービスの一部としてCE-CEコントロール交換処理を実現できるでしょう。 すなわち、プロバイダーネットワークは、CE-PE制御チャンネルの上に受け取られたコントロールメッセージをプロバイダーネットワークの反対側に移して、PE-CE制御チャンネルでそれらを提供します。 プロバイダーネットワークの中のこの実現はオペレータまで達していますが、プロバイダーネットワークがGMPLS制御飛行機を使用するところに、プロバイダー制御飛行機を通して顧客コントロール飛行機メッセージを転送できました、恐らくIPトンネルを使用して。
Care must be taken to protect the provider network and other
customers from Denial of Service (DoS) attack. Traffic saturation
over the control plane network needs to be carefully managed as
well. Note that if private addresses are assigned to the CE-PE
control channels, the provider network must support VPN-scoped
routing and forwarding for control messages.
サービス妨害(DoS)攻撃からプロバイダーネットワークと他の顧客を保護するために注意しなければなりません。 規制飛行機ネットワークの上のトラフィック飽和は、慎重にまた、管理される必要があります。 プライベート・アドレスがCE-PE制御チャンネルに割り当てられるなら、プロバイダーネットワークがコントロールメッセージのためのVPNによって見られたルーティングと推進をサポートしなければならないことに注意してください。
11. Manageability Considerations
11. 管理可能性問題
Manageability considerations for GMPLS are described in existing documents, such as [RFC3945]. Also, manageability considerations for L3VPN are described in existing documents, such as [RFC4176]. These manageability considerations should also be applied in L1VPNs, and these aspects are described in this section. In addition, there are some specific manageability considerations for L1VPNs, such as configuration and accounting.
GMPLSのための管理可能性問題は[RFC3945]などの既存のドキュメントで説明されます。 また、L3VPNのための管理可能性問題は[RFC4176]などの既存のドキュメントで説明されます。 また、これらの管理可能性問題はL1VPNsで適用されるべきです、そして、これらの局面はこのセクションで説明されます。 さらに、構成や会計などのL1VPNsのためのいくつかの特定の管理可能性問題があります。
o Fault management
o 障害管理
The provider network MUST support fault management. It MUST support liveness detection, and monitoring and verification of correct operation.
プロバイダーネットワークは障害管理をサポートしなければなりません。 それは正しい操作について活性検出、モニター、および検証をサポートしなければなりません。
Takeda Informational [Page 29] RFC 4847 Layer 1 VPN Framework April 2007
[29ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
When a failure occurs, the provider network SHOULD correlate the failure. Also, it SHOULD be able to detect which customer is affected by the failure.
失敗が起こると、プロバイダーネットワークSHOULDは失敗を関連させます。 それ、もSHOULD、どの顧客が失敗で影響を受けるか検出できてください。
If the provider network can resolve failures without intervention from the customer network, it MUST be possible to configure the provider network to not report failures to the customers. However, it MAY be part of an agreement between a customer and provider that failures are reported to the customer, regardless.
プロバイダーネットワークが顧客ネットワークから介入なしで失敗を決議できるなら、失敗を顧客に報告しないようにプロバイダーネットワークを構成するのは可能であるに違いありません。 しかしながら、それは失敗が不注意に顧客に報告されるという顧客とプロバイダーとの協定の一部であるかもしれません。
o Configuration management
o 構成管理
The provider network MUST support configuration management, such as the following.
プロバイダーネットワークは以下などの構成管理をサポートしなければなりません。
- Service mode/model configuration.
- モード/モデル構成を修理してください。
- Network representation configuration: Configuration of virtual
node and virtual link.
- 表現構成をネットワークでつないでください: 仮想ノードと仮想のリンクの構成。
- Resource allocation configuration: Dedicated, shared. See
Section 8 for more detail.
- 資源配分構成: ひたむきで、共有されています。 その他の詳細に関してセクション8を見てください。
- Recovery policy configuration: For example, recovery resource
sharing schemes, such as shared recovery, extra traffic. See
Section 9 for more detail.
- 回復方針構成: 例えば、回復リソース共有は共有された回復などのように付加的なトラフィックを計画します。 その他の詳細に関してセクション9を見てください。
- Membership configuration.
- 会員資格構成。
- Network/Element level configuration: For example, TE link
configuration.
- ネットワーク/要素の平らな構成: 例えば、TEは構成をリンクします。
It SHOULD be possible for the provider network to verify that
configuration is correctly made.
それ、SHOULD、プロバイダーネットワークが、構成が正しく作られていることを確かめるのにおいて、可能であってください。
o Accounting management
o 会計管理
The provider network MUST support accounting management. It MUST
be able to record usage of VPN connections for each customer.
プロバイダーネットワークは、会計が管理であるとサポートしなければなりません。 それは各顧客のためにVPN接続の使用法を記録できなければなりません。
o Performance management
o パフォーマンス管理
The provider network MUST support performance management.
プロバイダーネットワークは、性能が管理であるとサポートしなければなりません。
In particular, it MUST support performance monitoring of parameters
associated with the Service Level Agreement (SLA), such as bit
error rate per VPN connection, and SLA verification.
特に、サービス・レベル・アグリーメント(SLA)に関連しているパラメタの性能モニターをサポートしなければなりません、VPN接続あたりのビット誤り率や、SLA検証などのように。
Takeda Informational [Page 30] RFC 4847 Layer 1 VPN Framework April 2007
[30ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
In addition, it MUST support performance monitoring and analysis of
parameters related to the network and equipment not directly
associated with the SLA, such as network resource utilization.
さらに、性能がネットワークに関連するパラメタと直接SLAに関連づけられなかった設備のモニターと分析であるとサポートしなければなりません、ネットワーク資源利用などのように。
o Security management
o セキュリティ管理
The provider network MUST support security management. See Section
12 for details.
プロバイダーネットワークは、セキュリティが管理であるとサポートしなければなりません。 詳細に関してセクション12を見てください。
o Management systems
o マネージメントシステム
In order to support various management functionalities, the
provider network relies on management systems and related tools.
GMPLS protocols and potential extensions of GMPLS MUST be able to
work with management systems and related tools to provide such
functionalities.
様々な管理の機能性をサポートするために、プロバイダーネットワークはマネージメントシステムと関連する道具を当てにします。 GMPLS MUSTのGMPLSプロトコルと潜在的拡大は、マネージメントシステムで働くことができて、そのような機能性を提供するためにツールを関係づけました。
In particular, MIB modules for GMPLS protocols and potential
extensions MUST be supported.
特に、GMPLSプロトコルと潜在的拡大のためのMIBモジュールをサポートしなければなりません。
o Management of customer networks
o 顧客ネットワークの経営
Customers MAY outsource management of their network (especially CEs
and CE-CE links) to the provider network. In such case, the
provider MUST be able to manage the customer network, as well as
the provider network.
顧客は彼らのネットワーク(特にCEsとCE-CEリンク)の経営をプロバイダーネットワークに社外調達するかもしれません。 そのような場合では、プロバイダーは顧客ネットワーク、およびプロバイダーネットワークに対処できなければなりません。
12. Security Considerations
12. セキュリティ問題
Security is clearly one of the essential requirements in L1VPNs. In this section, key security requirements are highlighted. Security considerations for L3VPNs and L2VPNs are described in existing documents, such as [RFC4110], [RFC4111], and [RFC4664]. These security considerations should also be applied in L1VPNs, and these aspects are described in this section. In addition, there are some specific security considerations for L1VPNs, such as connectivity restriction and shared control links.
セキュリティは明確にL1VPNsの必須の条件の1つです。 このセクションで、主要なセキュリティ要件は強調されます。 L3VPNsとL2VPNsのためのセキュリティ問題は[RFC4110]や、[RFC4111]や、[RFC4664]などの既存のドキュメントで説明されます。 また、これらのセキュリティ問題はL1VPNsで適用されるべきです、そして、これらの局面はこのセクションで説明されます。 さらに、接続性制限や共有されたコントロールリンクなどのL1VPNsのためのいくつかの特定のセキュリティ問題があります。
This section first describes types of information to be secured. Then, security features or aspects are described. Finally, some considerations concerning scenarios where security mechanisms are applied is described.
このセクションは最初に、保証される情報のタイプについて説明します。 そして、セキュリティ機能か局面が説明されます。 最終的に、セキュリティー対策が適用されているシナリオに関するいくつかの問題が説明されます。
Takeda Informational [Page 31] RFC 4847 Layer 1 VPN Framework April 2007
[31ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
12.1. Types of Information
12.1. 情報のタイプ
It MUST be possible to secure the information exchanged between the customer and the provider. This includes data plane information, control plane information, and management plane information.
顧客とプロバイダーの間で交換された情報を保証するのは可能であるに違いありません。 これはデータ飛行機情報、コントロール飛行機情報、および管理飛行機情報を含んでいます。
At layer 1, data plane information is normally assumed to be secured once connections are established, since those connections are dedicated to each VPN. That is, it is not possible to communicate unless there is a connection. Therefore, in L1VPNs, the main concern of data plane security is restricting VPN connections to be used only within the same VPN, as described in Section 6.2. Note that a customer may wish to assure data plane information security against not only other customers, but also the provider. In such case, the customer may wish to apply their own security mechanisms for data plane information (CE-CE security), as later described.
層1では、通常、接続がいったん確立されるとデータ飛行機情報が機密保護されると思われます、それらの接続が各VPNに専念するので。 すなわち、接続がない場合、交信するのは可能ではありません。 したがって、L1VPNsでは、データ飛行機セキュリティの主な関心事は同じVPNだけの中で使用されるためにVPN接続を制限しています、セクション6.2で説明されるように。 顧客が他の顧客だけではなく、プロバイダーに対してもデータ飛行機情報セキュリティを保証したがっているかもしれないことに注意してください。 そのような場合では、顧客はデータ飛行機情報(CE-CEセキュリティ)のためにそれら自身のセキュリティー対策を適用したがっているかもしれません、後で説明されているとして。
In addition, information contained in the provider network MUST be secured. This includes VPN service contract information, current VPN connection information, VPN membership information, and system information. Note these types of information MAY be accessible to authorized entities.
さらに、プロバイダーネットワークに含まれた情報を保証しなければなりません。 これはVPN役務契約情報、現在のVPN接続情報、VPN会員資格情報、およびシステム情報を含んでいます。 これらのタイプの情報が権限のある機関にアクセス可能であるかもしれないことに注意してください。
12.2. Security Features
12.2. セキュリティ機能
Security features include the following:
セキュリティ機能は以下を含んでいます:
o Data integrity
o データの保全
The information exchanged between the customer and the provider
MUST be delivered unchanged.
変わりがない状態で顧客とプロバイダーの間で交換された情報を提供しなければなりません。
o Confidentiality
o 秘密性
The information exchanged between the customer and the provider
MUST NOT be disclosed to a third party.
顧客とプロバイダーの間で交換された情報を第三者に明らかにしてはいけません。
o Authentication
o 認証
The entity requesting the service to the provider MUST be
identified and have its identity authenticated, and the provider
providing the service MUST also be identified and have its identify
authenticated.
プロバイダーに対するサービスを要求する実体で特定されて、アイデンティティを認証しなければならなくて、また、サービスを提供するプロバイダーを特定しなければならない、有、それ、認証されて、特定します。
Takeda Informational [Page 32] RFC 4847 Layer 1 VPN Framework April 2007
[32ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
o Access control
o アクセス制御
Access to the information contained in the provider network, which
may be information about the customer networks or the existence of
customers, as well as about the provider network, MUST be
restricted to the authorized entity.
顧客ネットワークか顧客の存在、およびプロバイダーネットワークの情報であるかもしれないプロバイダーネットワークに含まれた情報へのアクセスを権限のある機関に制限しなければなりません。
o DoS attack detection and protection
o DoS攻撃検出と保護
The provider network MUST have mechanisms to detect DoS attack and
to protect against it reactively and proactively.
プロバイダーネットワークには、DoS攻撃を検出して、それから反動的に守って、予測するメカニズムがなければなりません。
12.3. Scenarios
12.3. シナリオ
There are two scenarios (or occasions) in which security mechanisms are applied. One is the service contract phase, where security mechanisms are applied once. The other is the service access phase, where security mechanisms are applied every time the service is requested.
セキュリティー対策が適用されている2つのシナリオ(または、時)があります。 1つは役務契約フェーズです。(そこでは、セキュリティー対策が一度適用されます)。 もう片方がサービスアクセスフェーズです。(そこでは、サービスが要求されているときはいつも、セキュリティー対策が適用されています)。
o Service contract scenario (static)
o 役務契約シナリオ(静電気)
This scenario includes the addition of new physical devices, such
as CE devices, data links and control links. It MUST be guaranteed
that these physical devices are connected to the right entity. In
addition, authority to access specific information MAY be given to
each customer as a part of service contract.
このシナリオはCEデバイスや、データ・リンクやコントロールリンクなどの新しいフィジカル・デバイスの追加を含んでいます。 これらのフィジカル・デバイスが正しい実体に接続されるのを保証しなければなりません。 さらに、役務契約の一部として特殊情報にアクセスする権威を各顧客に与えるかもしれません。
o Service access scenario (dynamic)
o サービスアクセスシナリオ(ダイナミック)です。
This scenario includes the reception of connection requests,
routing information exchange requests (e.g., attempts to establish
a neighbor relationship in routing protocols, or command request
via the management plane interface), and management information
retrieval requests. If a communication channel between the
customer and the provider (control channel, management interface)
is physically separate per customer, and the entity connected over
this communication channel is identified in the service contract
phase, the provider can ensure who is requesting the service.
Also, the communication channel could be considered as secure.
However, when communication channel is physically shared among
customers, security mechanisms MUST be available and SHOULD be
enforced. Examples of such security mechanisms include IPsec
[RFC4302] and [RFC4303]. Note that even in the case of physically
separate communication channels, customers may wish to apply
security mechanisms to assure higher security, and such mechanisms
MUST be available.
このシナリオは接続要求、ルーティング情報交換要求(例えば、管理飛行機インタフェースを通してルーティング・プロトコル、またはコマンド要求に隣人関係を確立するのを試みる)、および経営情報検索要求のレセプションを含んでいます。 顧客とプロバイダー(制御チャンネル、管理は連結する)の間の通信チャネルが顧客単位で肉体的に別々であり、この通信チャネルの上に関連づけられた実体が役務契約フェーズで特定されるなら、缶が確実にするサービスを要求しているプロバイダーです。 また、安全であると通信チャネルをみなすことができました。 しかしながら、いつ通信チャネルが顧客の中で共有されていて、物理的に、セキュリティー対策が利用可能でなければならないということであるか、そして、SHOULD、実施されてください。 そのようなセキュリティー対策に関する例はIPsec[RFC4302]と[RFC4303]を含んでいます。 肉体的に別々の通信チャネルの場合ではさえ、顧客が、より高いセキュリティを保証するためにセキュリティー対策を適用したがっているかもしれなくて、そのようなメカニズムが利用可能であるに違いないことに注意してください。
Takeda Informational [Page 33] RFC 4847 Layer 1 VPN Framework April 2007
[33ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
When the entity requesting the service is identified, the provider
MUST ensure that the request is authorized for that entity. This
includes assuring that connection request is between VPN end points
belonging to the same VPN.
サービスを要求する実体が特定されるとき、プロバイダーは、要求がその実体のために認可されるのを確実にしなければなりません。 これは、VPNエンドポイントの間には、接続要求が同じVPNに属しながらあることを保証するのを含んでいます。
Also note that customers may wish to apply their own security
mechanisms for data plane information (CE-CE security). This
includes IPsec [RFC4302] and [RFC4303] for IP traffic.
また、顧客がデータ飛行機情報(CE-CEセキュリティ)のためにそれら自身のセキュリティー対策を適用したがっているかもしれないことに注意してください。 これはIPトラフィックのためのIPsec[RFC4302]と[RFC4303]を含んでいます。
13. Acknowledgements
13. 承認
The material in this document is based on the work of the ITU-T Study Group 13.
材料は本書ではITU-T Study Group13の仕事に基づいています。
We would like to thank Dimitri Papadimitriou, Deborah Brungard, Yakov Rekhter, Alex Zinin, Igor Bryskin, Adrian Farrel, and Ross Callon for their useful comments and suggestions.
彼らの役に立つコメントと提案についてディミトリPapadimitriou、デボラBrungard、ヤコフRekhter、アレックス・ジニン、イーゴリBryskin、エードリアン・ファレル、およびロスCallonに感謝申し上げます。
Thanks to Mark Townsley, Dan Romascanu, and Cullen Jennings for helpful input during IESG review.
おかげに、IESGの間の有用な入力のためのマークTownsley、ダンRomascanu、およびCullenジョニングスは論評します。
14. Contributors
14. 貢献者
The foundation of this document is based heavily on the work of ITU-T Study Group 13, Question 11. SG13/Q11 has been investigating the service requirements and architecture for Layer 1 VPNs for some time, and the foundation of this document is a summary and development of the conclusions they have reached. Based on such material, the IETF and the L1VPN WG in particular have developed this framework and requirements for the support of L1VPNs by use of GMPLS protocols.
Question11、このドキュメントの基礎はずっしりとITU-T Study Group13の仕事に基づいています。 このドキュメントの基礎は、それらが達した結論のSG13/Q11がLayer1VPNsのためにしばらくサービス要件とアーキテクチャを調査していて、概要と開発です。 そのような材料に基づいて、IETFと特にL1VPN WGはGMPLSプロトコルの使用によるL1VPNsのサポートのためのこのフレームワークと要件を開発しました。
The details of this document are the result of contributions from several authors who are listed here in alphabetic order. Contact details for these authors can be found in a separate section near the end of this document.
このドキュメントの細部はここにアルファベット順に記載されている数人の作者からの貢献の結果です。 このドキュメントの端頃の別々のセクションでこれらの作者への詳細な連絡先を見つけることができます。
Raymond Aubin (Nortel) Marco Carugi (Nortel) Ichiro Inoue (NTT) Hamid Ould-Brahim (Nortel) Tomonori Takeda (NTT)
レイモンドオーバン(ノーテル)マルコCarugi(ノーテル)井上一郎(NTT)ハミドオールド-Brahim(ノーテル)Tomonori竹田(NTT)
Takeda Informational [Page 34] RFC 4847 Layer 1 VPN Framework April 2007
[34ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
15. Normative References
15. 引用規格
[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月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換えアーキテクチャ」、RFC3031、2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[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日
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3945] エドマニー、E.、RFC3945、「一般化されたマルチプロトコルラベルは(GMPLS)アーキテクチャを切り換えること」での10月2004日
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005.
[RFC4026] アンデションとL.とT.マドセン、「プロバイダーの食糧を供給された仮想私設網(VPN)用語」、RFC4026、2005年3月。
[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月。
[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月。
[Y.1312] Y.1312 - Layer 1 Virtual Private Network Generic
requirements and architecture elements, ITU-T
Recommendation, September 2003, available from
<http://www.itu.int>.
[Y.1312]Y.1312--1Virtualの兵士のNetwork Generic要件とアーキテクチャ要素、2003年9月に<http://www.itu.int>から利用可能なITU-T Recommendationを層にしてください。
16. Informative References
16. 有益な参照
[Y.1313] Y.1313 - Layer 1 Virtual Private Network service and
network architectures, ITU-T Recommendation, July 2004,
available from <http://www.itu.int>.
[Y.1313]Y.1313--1Virtualの兵士のNetworkサービスとネットワークアーキテクチャ、2004年7月に<http://www.itu.int>から利用可能なITU-T Recommendationを層にしてください。
Takeda Informational [Page 35] RFC 4847 Layer 1 VPN Framework April 2007
[35ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, July 2005.
[RFC4110] CallonとR.とM.鈴木、「層3のプロバイダーで食糧を供給された仮想私設網(PPVPNs)のためのフレームワーク」、RFC4110、2005年7月。
[RFC4111] Fang, L., Ed., "Security Framework for Provider-
Provisioned Virtual Private Networks (PPVPNs)", RFC 4111,
July 2005.
[RFC4111] 牙、L.、エド、「プロバイダーのためのセキュリティフレームワークは仮想私設網(PPVPNs)に食糧を供給した」RFC4111、7月2005日
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L.
Ong, "Requirements for Generalized MPLS (GMPLS) Signaling
Usage and Extensions for Automatically Switched Optical
Network (ASON)", RFC 4139, July 2005.
[RFC4139] Papadimitriou、D.、ドレイク、J.、灰、J.、ファレル、A.、L.オング、および「一般化されたMPLS(GMPLS)シグナリング用法のための要件と自動的に切り換えられた光学ネットワーク(ASON)のための拡大」、RFC4139(2005年7月)
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K.,
and A. Gonguet, "Framework for Layer 3 Virtual Private
Networks (L3VPN) Operations and Management", RFC 4176,
October 2005.
[RFC4176]高架鉄道Mghazli、Y.(エド)、ナドー、T.、Boucadair、M.、チェン、K.、およびA.Gonguet、「層3の仮想私設網(L3VPN)操作と管理のためのフレームワーク」RFC4176(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月。
[RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi-
Protocol Label Switching (GMPLS) Routing for the
Automatically Switched Optical Network (ASON)", RFC 4258,
November 2005.
[RFC4258]Brungard、D.(エド)、「一般化されたマルチプロトコルのための要件は自動的に切り換えられた光学ネットワーク(ASON)のために、切り換え(GMPLS)をルート設定とラベルします」、RFC4258、2005年11月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005
[RFC4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4303]ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
2006.
エド[RFC4427]マニー、E.(エド)、およびD.Papadimitriou、「一般化されたマルチプロトコルラベルのための回復(保護と王政復古)用語は(GMPLS)を切り換えること」でのRFC4427(2006年3月)。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for
Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664,
September 2006.
[RFC4664]アンデション、L.、エド、E.ローゼン、エド、「層2の仮想私設網(L2VPNs)のためのフレームワーク」、RFC4664、9月2006日
Takeda Informational [Page 36] RFC 4847 Layer 1 VPN Framework April 2007
[36ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
Authors' Addresses
作者のアドレス
Raymond Aubin Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 (613) 763 2208 EMail: aubin@nortel.com
レイモンドオーバンノーテルは私書箱3511駅のCオタワをK1Y 4H7カナダ電話にネットワークでつなぎます: +1(613) 763 2208はメールされます: aubin@nortel.com
Marco Carugi Nortel Networks S.A. Parc d'activites de Magny-Chateaufort Les Jeunes Bois - MS CTF 32B5 - Chateaufort 78928 YVELINES Cedex 9 - FRANCE Phone: +33 1 6955 7027 EMail: marco.carugi@nortel.com
マルコCarugiノーテルNetworks S.A.Parc d'activites deマニー-ChateaufortレスJeunes Bois--MS CTF 32B5--Chateaufort78928イブリーヌCedex9--フランス電話: +33 1 6955 7027はメールされます: marco.carugi@nortel.com
Ichiro Inoue NTT Network Service Systems Laboratories, NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6076 EMail: inoue.ichiro@lab.ntt.co.jp
イチロー井上NTTネットワーク・サービスシステム研究所、日本東京180-8585が電話をする3 9-11テロのNTT社の美土里町武蔵野市: +81 422 59 6076はメールされます: inoue.ichiro@lab.ntt.co.jp
Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 EMail: hbrahim@nortel.com
ハミドオールド-Brahimノーテルは私書箱3511駅のCオタワをK1Y 4H7カナダ電話にネットワークでつなぎます: +1(613) 765 3418はメールされます: hbrahim@nortel.com
Tomonori Takeda, Editor NTT Network Service Systems Laboratories, NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 7434 EMail : takeda.tomonori@lab.ntt.co.jp
Tomonori竹田、エディタNTTネットワーク・サービスシステム研究所、日本東京180-8585が電話をする3 9-11テロのNTT社の美土里町武蔵野市: +81 422 59 7434はメールされます: takeda.tomonori@lab.ntt.co.jp
Takeda Informational [Page 37] RFC 4847 Layer 1 VPN Framework April 2007
[37ページ]RFC4847層1のVPNフレームワーク2007年4月の情報の竹田
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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に情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Takeda Informational [Page 38]
竹田Informationalです。[38ページ]
一覧
スポンサーリンク
