RFC5085 日本語訳
5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV): AControl Channel for Pseudowires. T. Nadeau, Ed., C. Pignataro, Ed.. December 2007. (Format: TXT=67847 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Nadeau, Ed.
Request for Comments: 5085 C. Pignataro, Ed.
Category: Standards Track Cisco Systems, Inc.
December 2007
Network Working Group T. Nadeau, Ed. Request for Comments: 5085 C. Pignataro, Ed. Category: Standards Track Cisco Systems, Inc. December 2007
Pseudowire Virtual Circuit Connectivity Verification (VCCV):
A Control Channel for Pseudowires
Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires
Status of This Memo
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Abstract
Abstract
This document describes Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs.
This document describes Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs.
Nadeau & Pignataro Standards Track [Page 1] RFC 5085 PW VCCV December 2007
Nadeau & Pignataro Standards Track [Page 1] RFC 5085 PW VCCV December 2007
Table of Contents
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Specification of Requirements . . . . . . . . . . . . . . 5
2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of VCCV . . . . . . . . . . . . . . . . . . . . . . . 6
4. CC Types and CV Types . . . . . . . . . . . . . . . . . . . . 8
5. VCCV Control Channel for MPLS PWs . . . . . . . . . . . . . . 10
5.1. VCCV Control Channel Types for MPLS . . . . . . . . . . . 10
5.1.1. In-Band VCCV (Type 1) . . . . . . . . . . . . . . . . 11
5.1.2. Out-of-Band VCCV (Type 2) . . . . . . . . . . . . . . 12
5.1.3. TTL Expiry VCCV (Type 3) . . . . . . . . . . . . . . . 12
5.2. VCCV Connectivity Verification Types for MPLS . . . . . . 13
5.2.1. ICMP Ping . . . . . . . . . . . . . . . . . . . . . . 13
5.2.2. MPLS LSP Ping . . . . . . . . . . . . . . . . . . . . 13
5.3. VCCV Capability Advertisement for MPLS PWs . . . . . . . . 13
5.3.1. VCCV Capability Advertisement LDP Sub-TLV . . . . . . 14
6. VCCV Control Channel for L2TPv3/IP PWs . . . . . . . . . . . . 15
6.1. VCCV Control Channel Type for L2TPv3 . . . . . . . . . . . 16
6.2. VCCV Connectivity Verification Type for L2TPv3 . . . . . . 17
6.2.1. L2TPv3 VCCV using ICMP Ping . . . . . . . . . . . . . 17
6.3. L2TPv3 VCCV Capability Advertisement for L2TPv3 . . . . . 17
6.3.1. L2TPv3 VCCV Capability AVP . . . . . . . . . . . . . . 17
7. Capability Advertisement Selection . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8.1. VCCV Interface Parameters Sub-TLV . . . . . . . . . . . . 19
8.1.1. MPLS VCCV Control Channel (CC) Types . . . . . . . . . 19
8.1.2. MPLS VCCV Connectivity Verification (CV) Types . . . . 20
8.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 21
8.3. L2TPv3 Assignments . . . . . . . . . . . . . . . . . . . . 21
8.3.1. Control Message Attribute Value Pairs (AVPs) . . . . . 21
8.3.2. Default L2-Specific Sublayer Bits . . . . . . . . . . 21
8.3.3. ATM-Specific Sublayer Bits . . . . . . . . . . . . . . 21
8.3.4. VCCV Capability AVP Values . . . . . . . . . . . . . . 22
9. Congestion Considerations . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . 5 2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of VCCV . . . . . . . . . . . . . . . . . . . . . . . 6 4. CC Types and CV Types . . . . . . . . . . . . . . . . . . . . 8 5. VCCV Control Channel for MPLS PWs . . . . . . . . . . . . . . 10 5.1. VCCV Control Channel Types for MPLS . . . . . . . . . . . 10 5.1.1. In-Band VCCV (Type 1) . . . . . . . . . . . . . . . . 11 5.1.2. Out-of-Band VCCV (Type 2) . . . . . . . . . . . . . . 12 5.1.3. TTL Expiry VCCV (Type 3) . . . . . . . . . . . . . . . 12 5.2. VCCV Connectivity Verification Types for MPLS . . . . . . 13 5.2.1. ICMP Ping . . . . . . . . . . . . . . . . . . . . . . 13 5.2.2. MPLS LSP Ping . . . . . . . . . . . . . . . . . . . . 13 5.3. VCCV Capability Advertisement for MPLS PWs . . . . . . . . 13 5.3.1. VCCV Capability Advertisement LDP Sub-TLV . . . . . . 14 6. VCCV Control Channel for L2TPv3/IP PWs . . . . . . . . . . . . 15 6.1. VCCV Control Channel Type for L2TPv3 . . . . . . . . . . . 16 6.2. VCCV Connectivity Verification Type for L2TPv3 . . . . . . 17 6.2.1. L2TPv3 VCCV using ICMP Ping . . . . . . . . . . . . . 17 6.3. L2TPv3 VCCV Capability Advertisement for L2TPv3 . . . . . 17 6.3.1. L2TPv3 VCCV Capability AVP . . . . . . . . . . . . . . 17 7. Capability Advertisement Selection . . . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.1. VCCV Interface Parameters Sub-TLV . . . . . . . . . . . . 19 8.1.1. MPLS VCCV Control Channel (CC) Types . . . . . . . . . 19 8.1.2. MPLS VCCV Connectivity Verification (CV) Types . . . . 20 8.2. PW Associated Channel Type . . . . . . . . . . . . . . . . 21 8.3. L2TPv3 Assignments . . . . . . . . . . . . . . . . . . . . 21 8.3.1. Control Message Attribute Value Pairs (AVPs) . . . . . 21 8.3.2. Default L2-Specific Sublayer Bits . . . . . . . . . . 21 8.3.3. ATM-Specific Sublayer Bits . . . . . . . . . . . . . . 21 8.3.4. VCCV Capability AVP Values . . . . . . . . . . . . . . 22 9. Congestion Considerations . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . . 26
Nadeau & Pignataro Standards Track [Page 2] RFC 5085 PW VCCV December 2007
Nadeau & Pignataro Standards Track [Page 2] RFC 5085 PW VCCV December 2007
1. Introduction
1. Introduction
There is a need for fault detection and diagnostic mechanisms that can be used for end-to-end fault detection and diagnostics for a Pseudowire, as a means of determining the PW's true operational state. Operators have indicated in [RFC4377] and [RFC3916] that such a tool is required for PW operation and maintenance. This document defines a protocol called Virtual Circuit Connectivity Verification (VCCV) that satisfies these requirements. VCCV is, in its simplest description, a control channel between a pseudowire's ingress and egress points over which connectivity verification messages can be sent.
There is a need for fault detection and diagnostic mechanisms that can be used for end-to-end fault detection and diagnostics for a Pseudowire, as a means of determining the PW's true operational state. Operators have indicated in [RFC4377] and [RFC3916] that such a tool is required for PW operation and maintenance. This document defines a protocol called Virtual Circuit Connectivity Verification (VCCV) that satisfies these requirements. VCCV is, in its simplest description, a control channel between a pseudowire's ingress and egress points over which connectivity verification messages can be sent.
The Pseudowire Edge-to-Edge Emulation (PWE3) Working Group defines a mechanism that emulates the essential attributes of a telecommunications service (such as a T1 leased line or Frame Relay) over a variety of Packet Switched Network (PSN) types [RFC3985]. PWE3 is intended to provide only the minimum necessary functionality to emulate the service with the required degree of faithfulness for the given service definition. The required functions of PWs include encapsulating service-specific bit streams, cells, or PDUs arriving at an ingress port and carrying them across an IP path or MPLS tunnel. In some cases, it is necessary to perform other operations, such as managing their timing and order, to emulate the behavior and characteristics of the service to the required degree of faithfulness.
The Pseudowire Edge-to-Edge Emulation (PWE3) Working Group defines a mechanism that emulates the essential attributes of a telecommunications service (such as a T1 leased line or Frame Relay) over a variety of Packet Switched Network (PSN) types [RFC3985]. PWE3 is intended to provide only the minimum necessary functionality to emulate the service with the required degree of faithfulness for the given service definition. The required functions of PWs include encapsulating service-specific bit streams, cells, or PDUs arriving at an ingress port and carrying them across an IP path or MPLS tunnel. In some cases, it is necessary to perform other operations, such as managing their timing and order, to emulate the behavior and characteristics of the service to the required degree of faithfulness.
From the perspective of Customer Edge (CE) devices, the PW is characterized as an unshared link or circuit of the chosen service. In some cases, there may be deficiencies in the PW emulation that impact the traffic carried over a PW and therefore limit the applicability of this technology. These limitations must be fully described in the appropriate service-specific documentation.
From the perspective of Customer Edge (CE) devices, the PW is characterized as an unshared link or circuit of the chosen service. In some cases, there may be deficiencies in the PW emulation that impact the traffic carried over a PW and therefore limit the applicability of this technology. These limitations must be fully described in the appropriate service-specific documentation.
For each service type, there will be one default mode of operation that all PEs offering that service type must support. However, optional modes have been defined to improve the faithfulness of the emulated service, as well as to offer a means by which older implementations may support these services.
For each service type, there will be one default mode of operation that all PEs offering that service type must support. However, optional modes have been defined to improve the faithfulness of the emulated service, as well as to offer a means by which older implementations may support these services.
Figure 1 depicts the architecture of a pseudowire as defined in [RFC3985]. It further depicts where the VCCV control channel resides within this architecture, which will be discussed in detail shortly.
Figure 1 depicts the architecture of a pseudowire as defined in [RFC3985]. It further depicts where the VCCV control channel resides within this architecture, which will be discussed in detail shortly.
Nadeau & Pignataro Standards Track [Page 3] RFC 5085 PW VCCV December 2007
Nadeau & Pignataro Standards Track [Page 3] RFC 5085 PW VCCV December 2007
|<-------------- Emulated Service ---------------->|
| |<---------- VCCV ---------->| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| V V V V |
V AC +----+ +----+ AC V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
Native service Native service
|<-------------- Emulated Service ---------------->| | |<---------- VCCV ---------->| | | |<------- Pseudowire ------->| | | | | | | | |<-- PSN Tunnel -->| | | | V V V V | V AC +----+ +----+ AC V +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | Provider Edge 1 Provider Edge 2 | | | | | | Customer | | Customer Edge 1 | | Edge 2 | | | | Native service Native service
Figure 1: PWE3 VCCV Operation Reference Model
Figure 1: PWE3 VCCV Operation Reference Model
From Figure 1, Customer Edge (CE) routers CE1 and CE2 are attached to the emulated service via Attachment Circuits (ACs), and to each of the Provider Edge (PE) routers (PE1 and PE2, respectively). An AC can be a Frame Relay Data Link Connection Identifier (DLCI), an ATM Virtual Path Identifier / Virtual Channel Identifier (VPI/VCI), an Ethernet port, etc. The PE devices provide pseudowire emulation, enabling the CEs to communicate over the PSN. A pseudowire exists between these PEs traversing the provider network. VCCV provides several means of creating a control channel over the PW, between the PE routers that attach the PW.
From Figure 1, Customer Edge (CE) routers CE1 and CE2 are attached to the emulated service via Attachment Circuits (ACs), and to each of the Provider Edge (PE) routers (PE1 and PE2, respectively). An AC can be a Frame Relay Data Link Connection Identifier (DLCI), an ATM Virtual Path Identifier / Virtual Channel Identifier (VPI/VCI), an Ethernet port, etc. The PE devices provide pseudowire emulation, enabling the CEs to communicate over the PSN. A pseudowire exists between these PEs traversing the provider network. VCCV provides several means of creating a control channel over the PW, between the PE routers that attach the PW.
Figure 2 depicts how the VCCV control channel is associated with the pseudowire protocol stack.
Figure 2 depicts how the VCCV control channel is associated with the pseudowire protocol stack.
Nadeau & Pignataro Standards Track [Page 4] RFC 5085 PW VCCV December 2007
Nadeau & Pignataro Standards Track [Page 4] RFC 5085 PW VCCV December 2007
+-------------+ +-------------+
| Layer2 | | Layer2 |
| Emulated | < Emulated Service > | Emulated |
| Services | | Services |
+-------------+ +-------------+
| | VCCV/PW | |
|Demultiplexer| < Control Channel > |Demultiplexer|
+-------------+ +-------------+
| PSN | < PSN Tunnel > | PSN |
+-------------+ +-------------+
| Physical | | Physical |
+-----+-------+ +-----+-------+
| |
| ____ ___ ____ |
| _/ \___/ \ _/ \__ |
| / \__/ \_ |
| / \ |
+--------| MPLS or IP Network |---+
\ /
\ ___ ___ __ _/
\_/ \____/ \___/ \____/
+-------------+ +-------------+ | Layer2 | | Layer2 | | Emulated | < Emulated Service > | Emulated | | Services | | Services | +-------------+ +-------------+ | | VCCV/PW | | |Demultiplexer| < Control Channel > |Demultiplexer| +-------------+ +-------------+ | PSN | < PSN Tunnel > | PSN | +-------------+ +-------------+ | Physical | | Physical | +-----+-------+ +-----+-------+ | | | ____ ___ ____ | | _/ \___/ \ _/ \__ | | / \__/ \_ | | / \ | +--------| MPLS or IP Network |---+ \ / \ ___ ___ __ _/ \_/ \____/ \___/ \____/
Figure 2: PWE3 Protocol Stack Reference Model including the VCCV
Control Channel
Figure 2: PWE3 Protocol Stack Reference Model including the VCCV Control Channel
VCCV messages are encapsulated using the PWE3 encapsulation as described in Sections 5 and 6, so that they are handled and processed in the same manner (or in some cases, a similar manner) as the PW PDUs for which they provide a control channel. These VCCV messages are exchanged only after the capability (expressed as two VCCV type spaces, namely the VCCV Control Channel and Connectivity Verification Types) and desire to exchange such traffic has been advertised between the PEs (see Sections 5.3 and 6.3), and VCCV types chosen.
VCCV messages are encapsulated using the PWE3 encapsulation as described in Sections 5 and 6, so that they are handled and processed in the same manner (or in some cases, a similar manner) as the PW PDUs for which they provide a control channel. These VCCV messages are exchanged only after the capability (expressed as two VCCV type spaces, namely the VCCV Control Channel and Connectivity Verification Types) and desire to exchange such traffic has been advertised between the PEs (see Sections 5.3 and 6.3), and VCCV types chosen.
1.1. Specification of Requirements
1.1. Specification of Requirements
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].
2. Abbreviations
2. Abbreviations
AC Attachment Circuit [RFC3985].
AC Attachment Circuit [RFC3985].
AVP Attribute Value Pair [RFC3931].
AVP Attribute Value Pair [RFC3931].
CC Control Channel (used as CC Type).
CC Control Channel (used as CC Type).
Nadeau & Pignataro Standards Track [Page 5] RFC 5085 PW VCCV December 2007
Nadeau & Pignataro Standards Track [Page 5] RFC 5085 PW VCCV December 2007
CE Customer Edge.
CE Customer Edge.
CV Connectivity Verification (used as CV Type).
CV Connectivity Verification (used as CV Type).
CW Control Word [RFC3985].
CW Control Word [RFC3985].
L2SS L2-Specific Sublayer [RFC3931].
L2SS L2-Specific Sublayer [RFC3931].
LCCE L2TP Control Connection Endpoint [RFC3931].
LCCE L2TP Control Connection Endpoint [RFC3931].
OAM Operation and Maintenance.
OAM Operation and Maintenance.
PE Provider Edge.
PE Provider Edge.
PSN Packet Switched Network [RFC3985].
PSN Packet Switched Network [RFC3985].
PW Pseudowire [RFC3985].
PW Pseudowire [RFC3985].
PW-ACH PW Associated Channel Header [RFC4385].
PW-ACH PW Associated Channel Header [RFC4385].
VCCV Virtual Circuit Connectivity Verification.
VCCV Virtual Circuit Connectivity Verification.
3. Overview of VCCV
3. Overview of VCCV
The goal of VCCV is to verify and further diagnose the pseudowire forwarding path. To this end, VCCV is comprised of different components:
The goal of VCCV is to verify and further diagnose the pseudowire forwarding path. To this end, VCCV is comprised of different components:
o a means of signaling VCCV capabilities to a peer PE,
o a means of signaling VCCV capabilities to a peer PE,
o an encapsulation for the VCCV control channel messages that allows
the receiving PE to intercept, interpret, and process them locally
as OAM messages, and
o an encapsulation for the VCCV control channel messages that allows the receiving PE to intercept, interpret, and process them locally as OAM messages, and
o specifications for the operation of the various VCCV operational
modes transmitted within the VCCV messages.
o specifications for the operation of the various VCCV operational modes transmitted within the VCCV messages.
When a pseudowire is first signaled using the Label Distribution Protocol (LDP) [RFC4447] or the Layer Two Tunneling Protocol version 3 (L2TPv3) [RFC3931], a message is sent from the initiating PE to the receiving PE requesting that a pseudowire be set up. This message has been extended to include VCCV capability information (see Section 4). The VCCV capability information indicates to the receiving PE which combinations of Control Channel (CC) and Connectivity Verification (CV) Types it is capable of receiving. If the receiving PE agrees to establish the PW, it will return its capabilities in the subsequent signaling message to indicate which CC
When a pseudowire is first signaled using the Label Distribution Protocol (LDP) [RFC4447] or the Layer Two Tunneling Protocol version 3 (L2TPv3) [RFC3931], a message is sent from the initiating PE to the receiving PE requesting that a pseudowire be set up. This message has been extended to include VCCV capability information (see Section 4). The VCCV capability information indicates to the receiving PE which combinations of Control Channel (CC) and Connectivity Verification (CV) Types it is capable of receiving. If the receiving PE agrees to establish the PW, it will return its capabilities in the subsequent signaling message to indicate which CC
Nadeau & Pignataro Standards Track [Page 6] RFC 5085 PW VCCV December 2007
Nadeau & Pignataro Standards Track [Page 6] RFC 5085 PW VCCV December 2007
and CV Types it is capable of processing. Precedence rules for which CC and CV Type to choose in cases where more than one is specified in this message are defined in Section 7 of this document.
and CV Types it is capable of processing. Precedence rules for which CC and CV Type to choose in cases where more than one is specified in this message are defined in Section 7 of this document.
Once the PW is signaled, data for the PW will flow between the PEs terminating the PW. At this time, the PEs can begin transmitting VCCV messages based on the CC and CV Type combinations just discussed. To this end, VCCV defines an encapsulation for these messages that identifies them as belonging to the control channel for the PW. This encapsulation is designed to both allow the control channel to be processed functionally in the same manner as the data traffic for the PW in order to faithfully test the data plane for the PE, and allow the PE to intercept and process these VCCV messages instead of forwarding them out of the AC towards the CE as if they were data traffic. In this way, the most basic function of the VCCV control channel is to verify connectivity of the pseudowire and the data plane used to transport the data path for the pseudowire. It should be noted that because of the number of combinations of optional and mandatory data-plane encapsulations for PW data traffic, VCCV defines a number of Control Channel (CC) and Connectivity Verification (CV) types in order to support as many of these as possible. While designed to support most of the existing combinations (both mandatory and optional), VCCV does define a default CC and CV Type combination for each PW Demultiplexer type, as will be described in detail later in this document.
Once the PW is signaled, data for the PW will flow between the PEs terminating the PW. At this time, the PEs can begin transmitting VCCV messages based on the CC and CV Type combinations just discussed. To this end, VCCV defines an encapsulation for these messages that identifies them as belonging to the control channel for the PW. This encapsulation is designed to both allow the control channel to be processed functionally in the same manner as the data traffic for the PW in order to faithfully test the data plane for the PE, and allow the PE to intercept and process these VCCV messages instead of forwarding them out of the AC towards the CE as if they were data traffic. In this way, the most basic function of the VCCV control channel is to verify connectivity of the pseudowire and the data plane used to transport the data path for the pseudowire. It should be noted that because of the number of combinations of optional and mandatory data-plane encapsulations for PW data traffic, VCCV defines a number of Control Channel (CC) and Connectivity Verification (CV) types in order to support as many of these as possible. While designed to support most of the existing combinations (both mandatory and optional), VCCV does define a default CC and CV Type combination for each PW Demultiplexer type, as will be described in detail later in this document.
VCCV can be used both as a fault detection and/or a diagnostic tool for pseudowires. For example, an operator can periodically invoke VCCV on a timed, on-going basis for proactive connectivity verification on an active pseudowire, or on an ad hoc or as-needed basis as a means of manual connectivity verification. When invoking VCCV, the operator triggers a combination of one of its various CC Types and one of its various CV Types. The CV Types include LSP Ping [RFC4379] for MPLS PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs. We define a matrix of acceptable CC and CV Type combinations further in this specification.
VCCV can be used both as a fault detection and/or a diagnostic tool for pseudowires. For example, an operator can periodically invoke VCCV on a timed, on-going basis for proactive connectivity verification on an active pseudowire, or on an ad hoc or as-needed basis as a means of manual connectivity verification. When invoking VCCV, the operator triggers a combination of one of its various CC Types and one of its various CV Types. The CV Types include LSP Ping [RFC4379] for MPLS PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs. We define a matrix of acceptable CC and CV Type combinations further in this specification.
The control channel maintained by VCCV can additionally carry fault detection status between the endpoints of the pseudowire. Furthermore, this information can then be translated into the native OAM status codes used by the native access technologies, such as ATM, Frame-Relay or Ethernet. The specific details of such status interworking is out of the scope of this document, and is only noted here to illustrate the utility of VCCV for such purposes. Complete details can be found in [MSG-MAP] and [RFC4447].
The control channel maintained by VCCV can additionally carry fault detection status between the endpoints of the pseudowire. Furthermore, this information can then be translated into the native OAM status codes used by the native access technologies, such as ATM, Frame-Relay or Ethernet. The specific details of such status interworking is out of the scope of this document, and is only noted here to illustrate the utility of VCCV for such purposes. Complete details can be found in [MSG-MAP] and [RFC4447].
Nadeau & Pignataro Standards Track [Page 7] RFC 5085 PW VCCV December 2007
Nadeau & Pignataro Standards Track [Page 7] RFC 5085 PW VCCV December 2007
4. CC Types and CV Types
4. CC Types and CV Types
The VCCV Control Channel (CC) Type defines several possible types of control channel that VCCV can support. These control channels can in turn carry several types of protocols defined by the Connectivity Verification (CV) Type. VCCV potentially supports multiple CV Types concurrently, but it only supports the use of a single CC Type. The specific type or types of VCCV packets that can be accepted and sent by a router are indicated during capability advertisement as described in Sections 5.3 and 6.3. The various VCCV CV Types supported are used only when they apply to the context of the PW demultiplexer in use. For example, the LSP Ping CV Type should only be used when MPLS Labels are utilized as PW Demultiplexer.
The VCCV Control Channel (CC) Type defines several possible types of control channel that VCCV can support. These control channels can in turn carry several types of protocols defined by the Connectivity Verification (CV) Type. VCCV potentially supports multiple CV Types concurrently, but it only supports the use of a single CC Type. The specific type or types of VCCV packets that can be accepted and sent by a router are indicated during capability advertisement as described in Sections 5.3 and 6.3. The various VCCV CV Types supported are used only when they apply to the context of the PW demultiplexer in use. For example, the LSP Ping CV Type should only be used when MPLS Labels are utilized as PW Demultiplexer.
Once a set of VCCV capabilities is received and advertised, a CC Type and CV Type(s) that match both the received and transmitted capabilities can be selected. That is, a PE router needs to only allow Types that are both received and advertised to be selected, performing a logical AND between the received and transmitted bitflag fields. The specific CC Type and CV Type(s) are then chosen within the constraints and rules specified in Section 7. Once a specific CC Type has been chosen (i.e., it matches both the transmitted and received VCCV CC capability), transmitted and replied to, this CC Type MUST be the only one used until such time as the pseudowire is re-signaled. In addition, based on these rules and the procedures defined in Section 5.2 of [RFC4447], the pseudowire MUST be re- signaled if a different set of capabilities types is desired. The relevant portion of Section 5.2 of [RFC4447] is:
Once a set of VCCV capabilities is received and advertised, a CC Type and CV Type(s) that match both the received and transmitted capabilities can be selected. That is, a PE router needs to only allow Types that are both received and advertised to be selected, performing a logical AND between the received and transmitted bitflag fields. The specific CC Type and CV Type(s) are then chosen within the constraints and rules specified in Section 7. Once a specific CC Type has been chosen (i.e., it matches both the transmitted and received VCCV CC capability), transmitted and replied to, this CC Type MUST be the only one used until such time as the pseudowire is re-signaled. In addition, based on these rules and the procedures defined in Section 5.2 of [RFC4447], the pseudowire MUST be re- signaled if a different set of capabilities types is desired. The relevant portion of Section 5.2 of [RFC4447] is:
Interface Parameter Sub-TLV
Interface Parameter Sub-TLV
Note that as the "interface parameter sub-TLV" is part of the
FEC, the rules of LDP make it impossible to change the
interface parameters once the pseudowire has been set up.
Note that as the "interface parameter sub-TLV" is part of the FEC, the rules of LDP make it impossible to change the interface parameters once the pseudowire has been set up.
The CC and CV Type indicator fields are defined as 8-bit bitmasks used to indicate the specific CC or CV Type or Types (i.e., none, one, or more) of control channel packets that may be sent on the VCCV control channel. These values represent the numerical value corresponding to the actual bit being set in the bitfield. The definition of each CC and CV Type is dependent on the PW type context, either MPLS or L2TPv3, within which it is defined.
The CC and CV Type indicator fields are defined as 8-bit bitmasks used to indicate the specific CC or CV Type or Types (i.e., none, one, or more) of control channel packets that may be sent on the VCCV control channel. These values represent the numerical value corresponding to the actual bit being set in the bitfield. The definition of each CC and CV Type is dependent on the PW type context, either MPLS or L2TPv3, within which it is defined.
Nadeau & Pignataro Standards Track [Page 8] RFC 5085 PW VCCV December 2007
Nadeau & Pignataro Standards Track [Page 8] RFC 5085 PW VCCV December 2007
Control Channel (CC) Types:
Control Channel (CC) Types:
The defined values for CC Types for MPLS PWs are:
The defined values for CC Types for MPLS PWs are:
MPLS Control Channel (CC) Types:
MPLS Control Channel (CC) Types:
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b as
first nibble (PW-ACH, see [RFC4385])
Bit 1 (0x02) - Type 2: MPLS Router Alert Label
Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
Bit (Value) Description ============ ========================================== Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b as first nibble (PW-ACH, see [RFC4385]) Bit 1 (0x02) - Type 2: MPLS Router Alert Label Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1 Bit 3 (0x08) - Reserved Bit 4 (0x10) - Reserved Bit 5 (0x20) - Reserved Bit 6 (0x40) - Reserved Bit 7 (0x80) - Reserved
The defined values for CC Types for L2TPv3 PWs are:
The defined values for CC Types for L2TPv3 PWs are:
L2TPv3 Control Channel (CC) Types:
L2TPv3 Control Channel (CC) Types:
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - L2-Specific Sublayer with V-bit set
Bit 1 (0x02) - Reserved
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
Bit (Value) Description ============ ========================================== Bit 0 (0x01) - L2-Specific Sublayer with V-bit set Bit 1 (0x02) - Reserved Bit 2 (0x04) - Reserved Bit 3 (0x08) - Reserved Bit 4 (0x10) - Reserved Bit 5 (0x20) - Reserved Bit 6 (0x40) - Reserved Bit 7 (0x80) - Reserved
Connectivity Verification (CV) Types:
Connectivity Verification (CV) Types:
The defined values for CV Types for MPLS PWs are:
The defined values for CV Types for MPLS PWs are:
MPLS Connectivity Verification (CV) Types:
MPLS Connectivity Verification (CV) Types:
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - ICMP Ping
Bit 1 (0x02) - LSP Ping
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit (Value) Description ============ ========================================== Bit 0 (0x01) - ICMP Ping Bit 1 (0x02) - LSP Ping Bit 2 (0x04) - Reserved Bit 3 (0x08) - Reserved Bit 4 (0x10) - Reserved Bit 5 (0x20) - Reserved
Nadeau & Pignataro Standards Track [Page 9] RFC 5085 PW VCCV December 2007
Nadeau & Pignataro Standards Track [Page 9] RFC 5085 PW VCCV December 2007
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
Bit 6 (0x40) - Reserved Bit 7 (0x80) - Reserved
The defined values for CV Types for L2TPv3 PWs are:
The defined values for CV Types for L2TPv3 PWs are:
L2TPv3 Connectivity Verification (CV) Types:
L2TPv3 Connectivity Verification (CV) Types:
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - ICMP Ping
Bit 1 (0x02) - Reserved
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
Bit (Value) Description ============ ========================================== Bit 0 (0x01) - ICMP Ping Bit 1 (0x02) - Reserved Bit 2 (0x04) - Reserved Bit 3 (0x08) - Reserved Bit 4 (0x10) - Reserved Bit 5 (0x20) - Reserved Bit 6 (0x40) - Reserved Bit 7 (0x80) - Reserved
If none of the types above are supported, the entire CC and CV Type Indicator fields SHOULD be transmitted as 0x00 (i.e., all bits in the bitfield set to 0) to indicate this to the peer.
If none of the types above are supported, the entire CC and CV Type Indicator fields SHOULD be transmitted as 0x00 (i.e., all bits in the bitfield set to 0) to indicate this to the peer.
If no capability is signaled, then the peer MUST assume that the peer has no VCCV capability and follow the procedures specified in this document for this case.
If no capability is signaled, then the peer MUST assume that the peer has no VCCV capability and follow the procedures specified in this document for this case.
5. VCCV Control Channel for MPLS PWs
5. VCCV Control Channel for MPLS PWs
When MPLS is used to transport PW packets, VCCV packets are carried over the MPLS LSP as defined in this section. In order to apply IP monitoring tools to a PW, an operator may configure VCCV as a control channel for the PW between the PE's endpoints [RFC3985]. Packets sent across this channel from the source PE towards the destination PE either as in-band traffic with the PW's data, or out-of-band. In all cases, the control channel traffic is not forwarded past the PE endpoints towards the Customer Edge (CE) devices; instead, VCCV messages are intercepted at the PE endpoints for exception processing.
When MPLS is used to transport PW packets, VCCV packets are carried over the MPLS LSP as defined in this section. In order to apply IP monitoring tools to a PW, an operator may configure VCCV as a control channel for the PW between the PE's endpoints [RFC3985]. Packets sent across this channel from the source PE towards the destination PE either as in-band traffic with the PW's data, or out-of-band. In all cases, the control channel traffic is not forwarded past the PE endpoints towards the Customer Edge (CE) devices; instead, VCCV messages are intercepted at the PE endpoints for exception processing.
5.1. VCCV Control Channel Types for MPLS
5.1. VCCV Control Channel Types for MPLS
As already described in Section 4, the capability of which control channel types (CC Type) are supported is advertised by a PE. Once the receiving PE has chosen a CC Type mode to use, it MUST continue using this mode until such time as the PW is re-signaled. Thus, if a new CC Type is desired, the PW must be torn-down and re-established.
As already described in Section 4, the capability of which control channel types (CC Type) are supported is advertised by a PE. Once the receiving PE has chosen a CC Type mode to use, it MUST continue using this mode until such time as the PW is re-signaled. Thus, if a new CC Type is desired, the PW must be torn-down and re-established.
Nadeau & Pignataro Standards Track [Page 10] RFC 5085 PW VCCV December 2007
Nadeau & Pignataro Standards Track [Page 10] RFC 5085 PW VCCV December 2007
Ideally, such a control channel would be completely in-band (i.e., following the same data-plane faith as PW data). When a control word is present on the PW, it is possible to indicate the control channel by setting a bit in the control word header (see Section 5.1.1).
Ideally, such a control channel would be completely in-band (i.e., following the same data-plane faith as PW data). When a control word is present on the PW, it is possible to indicate the control channel by setting a bit in the control word header (see Section 5.1.1).
Section 5.1.1 through Section 5.1.3 describe each of the currently defined VCCV Control Channel Types (CC Types).
Section 5.1.1 through Section 5.1.3 describe each of the currently defined VCCV Control Channel Types (CC Types).
5.1.1. In-Band VCCV (Type 1)
5.1.1. In-Band VCCV (Type 1)
CC Type 1 is also referred to as "PWE3 Control Word with 0001b as first nibble". It uses the PW Associated Channel Header (PW-ACH); see Section 5 of [RFC4385].
CC Type 1 is also referred to as "PWE3 Control Word with 0001b as first nibble". It uses the PW Associated Channel Header (PW-ACH); see Section 5 of [RFC4385].
The PW set-up protocol [RFC4447] determines whether a PW uses a control word. When a control word is used, and that CW uses the "Generic PW MPLS Control Word" format (see Section 3 of [RFC4385]), a Control Channel for use of VCCV messages can be created by using the PW Associated Channel CW format (see Section 5 of [RFC4385]).
The PW set-up protocol [RFC4447] determines whether a PW uses a control word. When a control word is used, and that CW uses the "Generic PW MPLS Control Word" format (see Section 3 of [RFC4385]), a Control Channel for use of VCCV messages can be created by using the PW Associated Channel CW format (see Section 5 of [RFC4385]).
The PW Associated Channel for VCCV control channel traffic is defined in [RFC4385] as shown in Figure 3:
The PW Associated Channel for VCCV control channel traffic is defined in [RFC4385] as shown in Figure 3:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | Channel Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PW Associated Channel Header
Figure 3: PW Associated Channel Header
The first nibble is set to 0001b to indicate a channel associated with a pseudowire (see Section 5 of [RFC4385] and Section 3.6 of [RFC4446]). The Version and the Reserved fields are set to 0, and the Channel Type is set to 0x0021 for IPv4 and 0x0057 for IPv6 payloads.
0001bに最初の少量がpseudowireに関連しているチャンネルを示すように設定されます([RFC4385]のセクション5と[RFC4446]のセクション3.6を見てください)。 バージョンとReserved分野は0に設定されます、そして、英仏海峡TypeはIPv4のための0×0021とIPv6ペイロードのための0×0057へのセットです。
For example, Figure 4 shows how the Ethernet [RFC4448] PW-ACH would be received containing an LSP Ping payload corresponding to a choice of CC Type of 0x01 and a CV Type of 0x02:
例えば、図4は0×01のCC Typeと0×02のCV Typeの選択に対応するLSP Pingペイロードを含んでいて、どうイーサネット[RFC4448]PW-ACHを受け取るだろうかを示しています:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| 0x21 (IPv4) or 0x57 (IPv6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| 0×21 (IPv4)か0×57(IPv6)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PW Associated Channel Header for VCCV
図4: VCCVのためのPWの関連チャンネルヘッダー
Nadeau & Pignataro Standards Track [Page 11] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[11ページ]。
It should be noted that although some PW types are not required to carry the control word, this type of VCCV can only be used for those PW types that do employ the control word when it is in use. Further, this CC Type can only be used if the PW CW follows the "Generic PW MPLS Control Word" format. This mode of VCCV operation MUST be supported when the control word is present.
何人かのPWタイプは規制単語を運ぶのに必要ではありませんが、それが使用中であるときに規制単語を使うそれらのPWタイプにVCCVのこのタイプを使用できるだけであることに注意されるべきです。 さらに、PW CWが「ジェネリックPW MPLSコントロールWord」形式に続く場合にだけ、このCC Typeを使用できます。 規制単語が存在しているとき、VCCV操作のこのモードをサポートしなければなりません。
5.1.2. Out-of-Band VCCV (Type 2)
5.1.2. バンドで出ているVCCV(タイプ2)
CC Type 2 is also referred to as "MPLS Router Alert Label".
また、CC Type2は「MPLSルータ警戒ラベル」と呼ばれます。
A VCCV control channel can alternatively be created by using the MPLS router alert label [RFC3032] immediately above the PW label. It should be noted that this approach could result in a different Equal Cost Multi-Path (ECMP) hashing behavior than pseudowire PDUs, and thus result in the VCCV control channel traffic taking a path which differs from that of the actual data traffic under test. Please see Section 2 of [RFC4928].
あるいはまた、PWラベルのすぐ上のMPLSルータ警戒ラベル[RFC3032]を使用することによって、VCCV制御チャンネルを創造できます。 このアプローチは振舞いを論じ尽くすpseudowire PDUsと異なったEqual Cost Multi-経路(ECMP)をもたらして、テストの下の実際のデータ通信量のものと異なっている経路を取るVCCVコントロールチャンネルトラフィックでその結果結果をもたらすかもしれないことに注意されるべきです。 [RFC4928]のセクション2を見てください。
CC Type 2 can be used whether the PW is set-up with a Control Word present or not.
PWがControl Wordが存在しているセットアップであるか否かに関係なく、CC Type2を使用できます。
This is the preferred mode of VCCV operation when the Control Word is not present.
Control Wordが存在していないとき、これはVCCV操作の最もよく使われる方法です。
If the Control Word is in use on this PW, it MUST also be included before the VCCV message. This is done to avoid the different ECMP hashing behavior. In this case, the CW uses the PW-ACH format described in Section 5.1.1 (see Figures 3 and 4). If the Control Word is not in use on this PW, the VCCV message follows the PW Label directly.
また、Control WordがこのPWで使用中であるなら、VCCVメッセージの前にそれを含まなければなりません。 振舞いを論じ尽くす異なったECMPを避けるためにこれをします。 この場合、CWはセクション5.1.1で説明されたPW-ACH形式を使用します(図3と4を見てください)。 Control WordがこのPWで使用中でないなら、VCCVメッセージは直接PW Labelに続きます。
5.1.3. TTL Expiry VCCV (Type 3)
5.1.3. TTL満期VCCV(タイプ3)
CC Type 3 is also referred to as "MPLS PW Label with TTL == 1".
また、CC Type3は「MPLS PWはTTLで1インチと=をラベルする」と呼ばれます。
The TTL of the PW label can be set to 1 to force the packet to be processed within the destination router's control plane. This approach could also result in a different ECMP hashing behavior and VCCV messages taking a different path than the PW data traffic.
PWラベルのTTLはパケットが目的地のルータの制御飛行機の中に処理させられるように1に用意ができることができます。 また、このアプローチはPWデータ通信量より振舞いを論じ尽くす異なったECMPと異なった経路を取るVCCVメッセージをもたらすかもしれません。
CC Type 3 can be used whether the PW is set-up with a Control Word present or not.
PWがControl Wordが存在しているセットアップであるか否かに関係なく、CC Type3を使用できます。
If the Control Word is in use on this PW, it MUST also be included before the VCCV message. This is done to avoid the different ECMP hashing behavior. In this case, the CW uses the PW-ACH format
また、Control WordがこのPWで使用中であるなら、VCCVメッセージの前にそれを含まなければなりません。 振舞いを論じ尽くす異なったECMPを避けるためにこれをします。 この場合、CWはPW-ACH形式を使用します。
Nadeau & Pignataro Standards Track [Page 12] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[12ページ]。
described in Section 5.1.1 (see Figures 3 and 4). If the Control Word is not in use on this PW, the VCCV message follows the PW Label directly.
セクション5.1.1(図3と4を見る)では、説明されます。 Control WordがこのPWで使用中でないなら、VCCVメッセージは直接PW Labelに続きます。
5.2. VCCV Connectivity Verification Types for MPLS
5.2. MPLSのためのVCCV接続性検証タイプ
5.2.1. ICMP Ping
5.2.1. ICMPピング
When this optional connectivity verification mode is used, an ICMP Echo packet using the encoding specified in [RFC0792] (ICMPv4) or [RFC4443] (ICMPv6) achieves connectivity verification. Implementations MUST use ICMPv4 [RFC0792] if the signaling for VCCV used IPv4 addresses, or ICMPv6 [RFC4443] if IPv6 addresses were used. If the pseudowire is set up statically, then the encoding MUST use that which was used for the pseudowire in the configuration.
この任意の接続性検証モードが使用されているとき、[RFC0792](ICMPv4)か[RFC4443](ICMPv6)で指定されたコード化を使用するICMP Echoパケットは接続性検証を達成します。 IPv6アドレスが使用されたならVCCVのためのシグナリングがIPv4アドレス、またはICMPv6[RFC4443]を使用したなら、実装はICMPv4[RFC0792]を使用しなければなりません。 pseudowireが静的にセットアップされるなら、コード化は構成にpseudowireに使用されたそれを使用しなければなりません。
5.2.2. MPLS LSP Ping
5.2.2. MPLS LSPピング
The LSP Ping header MUST be used in accordance with [RFC4379] and MUST also contain the target FEC Stack containing the sub-TLV of sub- Type 8 for the "L2 VPN endpoint", 9 for "FEC 128 Pseudowire (deprecated)", 10 for "FEC 128 Pseudowire", or 11 for the "FEC 129 Pseudowire". The sub-TLV value indicates the PW to be verified.
LSP Pingヘッダーは、[RFC4379]に従って使用しなければならなくて、また、「L2 VPN終点」へのサブTypeのサブTLV8、「FEC128Pseudowire(推奨しない)」のための9、「FEC128Pseudowire」のための10、または「FEC129Pseudowire」のための11を含む目標FEC Stackを含まなければなりません。 サブTLV値は、確かめられるためにPWを示します。
5.3. VCCV Capability Advertisement for MPLS PWs
5.3. MPLS PWsのためのVCCV能力広告
To permit the indication of the type or types of PW control channel(s) and connectivity verification mode or modes over a particular PW, a VCCV parameter is defined in Section 5.3.1 that is used as part of the PW establishment signaling. When a PE signals a PW and desires PW OAM for that PW, it MUST indicate this during PW establishment using the messages defined in Section 5.3.1. Specifically, the PE MUST include the VCCV interface parameter sub- TLV (0x0C) assigned in [RFC4446] in the PW set-up message [RFC4447].
特定のPWの上でPW制御チャンネルと接続性検証モードかモードのタイプかタイプのしるしを可能にするために、VCCVパラメタはPW設立シグナリングの一部として使用されたセクション5.3.1で定義されます。 PEがPWに合図して、そのPWのためにPW OAMを望んでいるとき、セクション5.3.1で定義されたメッセージを使用して、それはPW設立の間、これを示さなければなりません。 明確に、PE MUSTはPWセットアップメッセージ[RFC4447]で[RFC4446]で割り当てられたVCCVインタフェース・パラメータサブTLV(0x0C)を含んでいます。
The decision of the type of VCCV control channel is left completely to the receiving control entity, although the set of choices is given by the sender in that it indicates the control channels and connectivity verification type or types that it can understand. The receiver SHOULD choose a single Control Channel Type from the match between the choices sent and received, based on the capability advertisement selection specified in Section 7, and it MUST continue to use this type for the duration of the life of the control channel. Changing Control Channel Types after one has been established to be in use could potentially cause problems at the receiving end and could also lead to interoperability issues; thus, it is NOT RECOMMENDED.
VCCV制御チャンネルのタイプの決定は完全に受信コントロール実体に任せます、制御チャンネルと接続性検証タイプを示すか、または理解できるのをタイプするので、選択のセットは送付者によって与えられていますが。 受信機SHOULDは送られて、セクション7で指定された能力広告選択に基づいて受けられた選択の間のマッチから独身のControl Channel Typeを選びます、そして、それは制御チャンネルの寿命の持続時間にこのタイプを使用し続けなければなりません。 1つが使用中になるように設立された後にControl Channel Typesを変えるのは、犠牲者に潜在的に問題を起こすことができて、また、相互運用性問題に通じるかもしれません。 したがって、それはNOT RECOMMENDEDです。
Nadeau & Pignataro Standards Track [Page 13] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[13ページ]。
When a PE sends a label mapping message for a PW, it uses the VCCV parameter to indicate the type of OAM control channels and connectivity verification type or types it is willing to receive and can send on that PW. A remote PE MUST NOT send VCCV messages before the capability of supporting the control channel(s) (and connectivity verification type(s) to be used over them) is signaled. Then, it can do so only on a control channel and using the connectivity verification type(s) from the ones indicated.
PEがPWへのラベルマッピングメッセージを送るとき、それは、OAM制御チャンネルと接続性検証タイプかそれが受け取っても構わないと思っているタイプのタイプを示すのにVCCVパラメタを使用して、そのPWを転送できます。 コントロールがチャンネル(s)(そして、それらの上で使用されるべき接続性検証タイプ)であるとサポートする能力が合図される前にリモートPE MUST NOTはメッセージをVCCVに送ります。 そして、制御チャンネルと接続性を使用するのにだけ、ものからの検証タイプが示したそれがそうできます。
If a PE receives VCCV messages prior to advertising capability for this message, it MUST discard these messages and not reply to them. In this case, the PE SHOULD increment an error counter and optionally issue a system and/or SNMP notification to indicate to the system administrator that this condition exists.
PEが広告能力の前にこのメッセージのためにVCCVメッセージを受け取るなら、それは、これらのメッセージを捨てて、それらに答えてはいけません。 この場合、PE SHOULDは、誤りカウンタを増加して、この状態が存在するのをシステム管理者に示すために任意にシステム、そして/または、SNMPに通知を発行します。
When LDP is used as the PW signaling protocol, the requesting PE indicates its configured VCCV capability or capabilities to the remote PE by including the VCCV parameter with appropriate options in the VCCV interface parameter sub-TLV field of the PW ID FEC TLV (FEC 128) or in the interface parameter sub-TLV of the Generalized PW ID FEC TLV (FEC 129). These options indicate which control channel and connectivity verification types it supports. The requesting PE MAY indicate that it supports multiple control channel options, and in doing so, it agrees to support any and all indicated types if transmitted to it. However, it MUST do so in accordance with the rules stipulated in Section 5.3.1 (VCCV Capability Advertisement Sub- TLV.)
PWシグナリングが議定書を作るとき自由民主党が使用されているとき、要求しているPEは、PW ID FEC TLVのVCCVインタフェース・パラメータサブTLV分野(FEC128)かGeneralized PW ID FEC TLVのインタフェース・パラメータサブTLV(FEC129)における適切なオプションでVCCVパラメタを含んでいることによって、リモートPEへのその構成されたVCCV能力か能力を示します。 これらのオプションは、それがどの制御チャンネルと接続性検証タイプを支えるかを示します。 要求しているPE MAYは、複合管理がチャンネルオプションであるとサポートするのを示します、そして、そうする際に、それに伝えられるなら、それは示されたタイプをいくらか、そして、皆、サポートするのに同意します。 しかしながら、セクション5.3.1で規定された規則に従って、それはそうしなければなりません。(VCCV能力広告サブTLV。)
Local policy may direct the PE to support certain OAM capability and to indicate it. The absence of the VCCV parameter indicates that no OAM functions are supported by the requesting PE, and thus the receiving PE MUST NOT send any VCCV control channel traffic to it. The reception of a VCCV parameter with no options set MUST be ignored as if one is not transmitted at all.
ローカルの方針はあるOAMが能力であるとサポートして、それを示すようPEに指示するかもしれません。 VCCVパラメタの欠如は、OAM機能が全く要求しているPEによってサポートされないのを示します、そして、その結果、受信PE MUST NOTはどんなVCCVコントロールチャンネルトラフィックもそれに送ります。 まるで1が全く伝えられないかのようにオプションが全くセットしていないVCCVパラメタのレセプションを無視しなければなりません。
The receiving PE similarly indicates its supported control channel types in the label mapping message. These may or may not be the same as the ones that were sent to it. The sender should examine the set that is returned to understand which control channels it may establish with the remote peer, as specified in Sections 4 and 7. Similarly, it MUST NOT send control channel traffic to the remote PE for which the remote PE has not indicated it supports.
受信PEは、サポートしている制御チャンネルがラベルマッピングメッセージをタイプするのを同様に示します。 これらはそれに送られたものと同じであるかもしれません。 送付者はそれがリモート同輩と共にどの制御チャンネルを確立するかもしれないかを理解するために返されるセットを調べるべきです、セクション4と7で指定されるように。 同様に、それはリモートPEがサポートするのを示していないリモートPEにコントロールチャンネルトラフィックを送ってはいけません。
5.3.1. VCCV Capability Advertisement LDP Sub-TLV
5.3.1. VCCV能力広告自由民主党サブTLV
[RFC4447] defines an Interface Parameter Sub-TLV field in the LDP PW ID FEC (FEC 128) and an Interface Parameters TLV in the LDP Generalized PW ID FEC (FEC 129) to signal different capabilities for
異なった能力に合図するために、LDP PW ID FECのInterface Parameter Sub-TLV分野(FEC128)と自由民主党Generalized PW ID FECのInterface Parameters TLV(FEC129)を定義します[RFC4447]。
Nadeau & Pignataro Standards Track [Page 14] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[14ページ]。
specific PWs. An optional sub-TLV parameter is defined to indicate the capability of supporting none, one, or more control channel and connectivity verification types for VCCV. This is the VCCV parameter field. If FEC 128 is used, the VCCV parameter field is carried in the Interface Parameter sub-TLV field. If FEC 129 is used, it is carried as an Interface Parameter sub-TLV in the Interface Parameters TLV.
特定のPWs。 任意のサブTLVパラメタはなにもサポートしない能力を示すために定義されます、と1つ以上の制御チャンネルと接続性検証がVCCVのためにタイプします。 これはVCCVパラメタ分野です。 FEC128が使用されているなら、VCCVパラメタ野原はInterface ParameterサブTLV分野で運ばれます。 FEC129が使用されているなら、それはInterface Parameters TLVのサブTLVのInterface Parameterとして運ばれます。
The VCCV parameter ID is defined as follows in [RFC4446]:
VCCVパラメタIDは以下の通り[RFC4446]で定義されます:
Parameter ID Length Description
0x0c 4 VCCV
パラメタID長さの記述0x0c4VCCV
The format of the VCCV parameter field is as follows:
VCCVパラメタ分野の形式は以下の通りです:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0c | 0x04 | CC Types | CV Types |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x0c| 0×04| CCはタイプされます。| CVはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Control Channel Type field (CC Type) defines a bitmask used to indicate the type of control channel(s) (i.e., none, one, or more) that a router is capable of receiving control channel traffic on. If more than one control channel is specified, the router agrees to accept control traffic over either control channel; however, see the rules specified in Sections 4 and 7 for more details. If none of the types are supported, a CC Type Indicator of 0x00 SHOULD be transmitted to indicate this to the peer. However, if no capability is signaled, then the PE MUST assume that its peer is incapable of receiving any of the VCCV CC Types and MUST NOT send any OAM control channel traffic to it. Note that the CC and CV Types definitions are consistent regardless of the PW's transport or access circuit type. The CC and CV Type values are defined in Section 4.
Control Channel Type分野(CC Type)はルータがコントロールチャンネルトラフィックを受けることができる制御チャンネル(すなわち、なにも、1つ、または以上)のタイプを示すのにおいて中古のビットマスクを定義します。 1個以上の制御チャンネルが指定されるなら、ルータは、どちらの制御チャンネルの上にもコントロールトラフィックを受け入れるのに同意します。 しかしながら、規則がセクション4と7でその他の詳細に指定されるのを見てください。 タイプのだれであるならも、サポートしているa CC Type Indicatorは0×00SHOULDのものではありません。これを同輩に示すために、伝えられます。 しかしながら、能力が全く合図されないなら、PE MUSTは、同輩がVCCV CC Typesのどれかを受けることができないで、少しのOAMコントロールチャンネルトラフィックもそれに送ってはいけないと仮定します。 CCとCV Types定義がPWの輸送かアクセス回路タイプにかかわらず一貫していることに注意してください。 CCとCV Type値はセクション4で定義されます。
6. VCCV Control Channel for L2TPv3/IP PWs
6. L2TPv3/IP PWsのVCCV制御チャンネル
When L2TPv3 is used to set up a PW over an IP PSN, VCCV packets are carried over the L2TPv3 session as defined in this section. L2TPv3 provides a "Hello" keepalive mechanism for the L2TPv3 control plane that operates in-band over IP or UDP (see Section 4.4 of [RFC3931]). This built-in Hello facility provides dead peer and path detection only for the group of sessions associated with the L2TP Control Connection. VCCV, however, allows individual L2TP sessions to be tested. This provides a more granular mechanism which can be used to troubleshoot potential problems within the data plane of L2TP endpoints themselves, or to provide additional connection status of individual pseudowires.
L2TPv3がIP PSNの上にPWをセットアップするのに使用されるとき、VCCVパケットはL2TPv3セッションの間、このセクションで定義されるように運ばれます。 L2TPv3はIPかUDPの上でバンドであることで運転するL2TPv3制御飛行機に「こんにちは」というkeepaliveメカニズムを供給します([RFC3931]のセクション4.4を見てください)。 この内蔵のHello施設はL2TP Control Connectionに関連しているセッションのグループのための死んでいる同輩と経路検出だけを提供します。 しかしながら、VCCVは、個々のL2TPセッションがテストされるのを許容します。 これはL2TP終点自体のデータ飛行機の中に潜在的な問題を障害調査するか、または個々のpseudowiresの追加接続形態を提供するのに使用できるより粒状のメカニズムを提供します。
Nadeau & Pignataro Standards Track [Page 15] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[15ページ]。
The capability of which Control Channel Type (CC Type) to use is advertised by a PE to indicate which of the potentially various control channel types are supported. Once the receiving PE has chosen a mode to use, it MUST continue using this mode until such time as the PW is re-signaled. Thus, if a new CC Type is desired, the PW must be torn down and re-established.
どのControl Channel Type(CC Type)を使用したらよいかに関する能力は、潜在的に様々なコントロールチャンネル種別のどれがサポートされるかを示すためにPEによって広告を出されます。 受信PEがいったん使用するモードを選ぶと、それは、PWのような時間が再合図されるまでこのモードを使用し続けなければなりません。 したがって、新しいCC Typeが望まれているなら、PWを取りこわされて、復職させなければなりません。
An LCCE sends VCCV messages on an L2TPv3-signaled pseudowire for fault detection and diagnostic of the L2TPv3 session. The VCCV message travels in-band with the Session and follows the exact same path as the user data for the session, because the IP header and L2TPv3 Session header are identical. The egress LCCE of the L2TPv3 session intercepts and processes the VCCV message, and verifies the signaling and forwarding state of the pseudowire on reception of the VCCV message. It is to be noted that the VCCV mechanism for L2TPv3 is primarily targeted at verifying the pseudowire forwarding and signaling state at the egress LCCE. It also helps when L2TPv3 Control Connection and Session paths are not identical.
LCCEはL2TPv3セッションの欠点検出と病気の特徴のためにL2TPv3によって合図されたpseudowireでメッセージをVCCVに送ります。 VCCVメッセージは、Sessionと共にバンドで旅行して、セッションのための利用者データと全く同じ経路に続きます、IPヘッダーとL2TPv3 Sessionヘッダーが同じであるので。 L2TPv3セッションの出口LCCEはVCCVメッセージのレセプションでVCCVメッセージを傍受して、処理して、pseudowireのシグナリングと推進状態について確かめます。 L2TPv3のためのVCCVメカニズムが主として出口LCCEで状態を進めて、合図するpseudowireについて確かめるのに狙うことに注意されることになっています。 また、それは、L2TPv3 Control ConnectionとSession経路が同じでないことを助けます。
6.1. VCCV Control Channel Type for L2TPv3
6.1. L2TPv3のためのVCCVコントロールチャンネルタイプ
In order to carry VCCV messages within an L2TPv3 session data packet, the PW MUST be established such that an L2-Specific Sublayer (L2SS) that defines the V-bit is present. This document defines the V-bit for the Default L2-Specific Sublayer [RFC3931] and the ATM-Specific Sublayer [RFC4454] using the Bit 0 position (see Sections 8.3.2 and 8.3.3). The L2-Specific Sublayer presence and type (either the Default or a PW-Specific L2SS) is signaled via the L2-Specific Sublayer AVP, Attribute Type 69, as defined in [RFC3931]. The V-bit within the L2-Specific Sublayer is used to identify that a VCCV message follows, and when the V-bit is set the L2SS has the format shown in Figure 5:
VCCVは運ぶためにL2TPv3セッションデータ・パケットの中で通信します、PW MUST。V-ビットを定義するL2特有のSublayer(L2SS)が存在しているように、設立されてください。 セクション8.3.2と8.3を見てください。このドキュメントがDefault L2特有のSublayer[RFC3931]とATM特有のSublayer[RFC4454]のためにBit0位置を使用することでV-ビットを定義する、(.3)。 L2特有のSublayer存在とタイプ(DefaultかPW特有のL2SSのどちらか)はL2特有のSublayer AVPを通して合図されます、Attribute Type69、[RFC3931]で定義されるように。 L2特有のSublayerの中のV-ビットはVCCVメッセージが従うのを特定するのに使用されます、そして、V-ビットが設定されるとき、L2SSには、図5に示された書式があります:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0 0 0|Version| Reserved | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0 0 0|バージョン| 予約されます。| チャンネルタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: L2-Specific Sublayer Format when the V-bit (bit 0) is set
図5: V-ビット(ビット0)があるとき、L2特有のSublayer Formatはセットしました。
The VCCV messages are distinguished from user data by the V-bit. The V-bit is set to 1, indicating that a VCCV session message follows. The next three bits MUST be set to 0 when sending and ignored upon receipt. The remaining fields comprising 28 bits (i.e., Version, Reserved, and Channel Type) follow the same definition, format, and number registry from Section 5 of [RFC4385].
VCCVメッセージはV-ビットによって利用者データと区別されます。 VCCVセッションメッセージが従うのを示して、V-ビットは1に設定されます。 次の3ビットを発信するとき、0に設定されて、領収書で無視しなければなりません。 28ビット(すなわち、バージョン、Reserved、およびChannel Type)を包括する残っているフィールドは[RFC4385]のセクション5から同じ定義、形式、および数の登録に続きます。
Nadeau & Pignataro Standards Track [Page 16] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[16ページ]。
The Version and Reserved fields are set to 0. For the CV Type currently defined of ICMP Ping (0x01), the Channel Type can indicate IPv4 (0x0021) or IPv6 (0x0057) (see [RFC4385]) as the VCCV payload directly following the L2SS.
バージョンとReserved分野は0に設定されます。 現在ICMP Ping(0×01)について定義されているCV Typeに関しては、直接L2SSに続いて、英仏海峡TypeはVCCVペイロードとしてIPv4(0×0021)かIPv6(0×0057)([RFC4385]を見ます)を示すことができます。
6.2. VCCV Connectivity Verification Type for L2TPv3
6.2. L2TPv3のためのVCCV接続性検証タイプ
The VCCV message over L2TPv3 directly follows the L2-Specific Sublayer with the V-bit set. It MUST contain an ICMP Echo packet as described in Section 6.2.1.
L2TPv3の上のVCCVメッセージはV-ビットセットと共にL2特有のSublayerに直接続きます。 それはセクション6.2.1で説明されるようにICMP Echoパケットを含まなければなりません。
6.2.1. L2TPv3 VCCV using ICMP Ping
6.2.1. ICMPピングを使用するL2TPv3 VCCV
When this connectivity verification mode is used, an ICMP Echo packet using the encoding specified in [RFC0792] for (ICMPv4) or [RFC4443] (for ICMPv6) achieves connectivity verification. Implementations MUST use ICMPv4 [RFC0792] if the signaling for the L2TPv3 PW used IPv4 addresses, or ICMPv6 [RFC4443] if IPv6 addresses were used. If the pseudowire is set-up statically, then the encoding MUST use that which was used for the pseudowire in the configuration.
この接続性検証モードが使用されているとき、[RFC0792]で(ICMPv4)か[RFC4443](ICMPv6のための)に指定されたコード化を使用するICMP Echoパケットは接続性検証を達成します。 IPv6アドレスが使用されたならL2TPv3 PWのためのシグナリングがIPv4アドレス、またはICMPv6[RFC4443]を使用したなら、実装はICMPv4[RFC0792]を使用しなければなりません。 pseudowireが静的にセットアップであるなら、コード化は構成にpseudowireに使用されたそれを使用しなければなりません。
The ICMP Ping packet directly follows the L2SS with the V-bit set. In the ICMP Echo request, the IP Header fields MUST have the following values: the destination IP address is set to the remote LCCE's IP address for the tunnel endpoint, the source IP address is set to the local LCCE's IP address for the tunnel endpoint, and the TTL or Hop Limit is set to 1.
ICMP PingパケットはV-ビットセットと共にL2SSに直接続きます。 ICMP Echo要求では、IP Header分野は以下の値を持たなければなりません: 送付先IPアドレスはトンネル終点へのリモートLCCEのIPアドレスに設定されます、そして、ソースIPアドレスはトンネル終点への地方のLCCEのIPアドレスに設定されます、そして、TTLかHop Limitが1に用意ができています。
6.3. L2TPv3 VCCV Capability Advertisement for L2TPv3
6.3. L2TPv3のためのL2TPv3 VCCV能力広告
A new optional AVP is defined in Section 6.3.1 to indicate the VCCV capabilities during session establishment. An LCCE MUST signal its desire to use connectivity verification for a particular L2TPv3 session and its VCCV capabilities using the VCCV Capability AVP.
新しい任意のAVPは、セッション設立の間、VCCV能力を示すためにセクション6.3.1で定義されます。 VCCV Capability AVPを使用することでLCCE MUSTは特定のL2TPv3セッションに接続性検証を使用する願望とそのVCCV能力に合図します。
An LCCE MUST NOT send VCCV packets on an L2TPv3 session unless it has received VCCV capability by means of the VCCV Capability AVP from the remote end. If an LCCE receives VCCV packets and it is not VCCV capable or it has not sent VCCV capability indication to the remote end, it MUST discard these messages. It should also increment an error counter. In this case the LCCE MAY optionally issue a system and/or SNMP notification.
それがリモートエンドからのVCCV Capability AVPによってVCCV能力を受けていない場合、LCCE MUST NOTはL2TPv3セッションのときにパケットをVCCVに送ります。 LCCEがVCCVパケットを受けて、それができるVCCVでないリモートエンドへの能力指示をVCCVに送らないなら、それはこれらのメッセージを捨てなければなりません。 また、それは誤りカウンタを増加するべきです。 この場合、LCCE MAYは任意にシステム、そして/または、SNMPに通知を発行します。
6.3.1. L2TPv3 VCCV Capability AVP
6.3.1. L2TPv3 VCCV能力AVP
The "VCCV Capability AVP", Attribute Type 96, specifies the VCCV capabilities as a pair of bitflags for the Control Channel (CC) and Connectivity Verification (CV) Types. This AVP is exchanged during
「VCCV能力AVP」(Attribute Type96)はControl Channel(CC)に対にしbitflagsのVCCV能力を指定します、そして、Connectivity Verification(CV)はタイプします。 このAVPを交換します。
Nadeau & Pignataro Standards Track [Page 17] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[17ページ]。
session establishment (in ICRQ (Incoming-Call-Request), ICRP (Incoming-Call-Reply), OCRQ (Outgoing-Call-Request), or OCRP (Outgoing-Call-Reply) messages). The value field has the following format:
セッション設立(ICRQ(入って来る呼び出し要求)、ICRP(入って来る呼び出し回答)、OCRQ(送信する呼び出し要求)、またはOCRP(外向的な呼び出し回答)メッセージの)。 値の分野には、以下の形式があります:
VCCV Capability AVP (ICRQ, ICRP, OCRQ, OCRP)
VCCV能力AVP(ICRQ、ICRP、OCRQ、OCRP)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CC Types | CV Types |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CCはタイプされます。| CVはタイプします。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CC Types:
CCはタイプされます:
The Control Channel (CC) Types field defines a bitmask used to
indicate the type of control channel(s) that may be used to
receive OAM traffic on for the given Session. The router agrees
to accept VCCV traffic at any time over any of the signaled VCCV
control channel types. CC Type values are defined in Section 4.
Although there is only one value defined in this document, the CC
Types field is included for forward compatibility should further
CC Types need to be defined in the future.
タイプがさばくControl Channel(CC)は与えられたSessionに、オンなOAMトラフィックを受けるのに使用されるかもしれない制御チャンネルのタイプを示すのにおいて中古のビットマスクを定義します。 ルータは、いつでも合図されたVCCVコントロールチャンネル種別のどれかでVCCVトラフィックを受け入れるのに同意します。 CC Type値はセクション4で定義されます。 定義された1つの値しかありませんが、このドキュメント、分野が含まれているCC Typesでは、下位互換はTypesが将来定義されるために必要とするCCを促進するべきです。
A CC Type of 0x01 may only be requested when there is an L2-
Specific Sublayer that defines the V-bit present. If a CC Type of
0x01 is requested without requesting an L2-Specific Sublayer AVP
with an L2SS type that defines the V-bit, the session MUST be
disconnected with a Call-Disconnect-Notify (CDN) message.
V-ビットプレゼントを定義するL2の特定のSublayerがあるときだけ、0×01のCC Typeは要求されるかもしれません。 0×01のCC TypeがV-ビットを定義するL2SSタイプでL2特有のSublayer AVPを要求しないで要求されるなら、Call分離に通知している(CDN)メッセージでセッションから切断しなければなりません。
If no CC Type is supported, a CC Type Indicator of 0x00 SHOULD be
sent.
どんなCC Typeも0×00SHOULDのサポートしているa CC Type Indicatorでないなら、送ってください。
CV Types:
CVはタイプします:
The Connectivity Verification (CV) Types field defines a bitmask
used to indicate the specific type or types (i.e., none, one, or
more) of control packets that may be sent on the specified VCCV
control channel. CV Type values are defined in Section 4.
タイプがさばくConnectivity Verification(CV)は特定のタイプを示すのに使用されるビットマスクを定義するか、または指定されたVCCV制御チャンネルで送られるかもしれないコントロールパケットの(すなわち、なにも、1つ、または以上)をタイプします。 CV Type値はセクション4で定義されます。
If no VCCV Capability AVP is signaled, then the LCCE MUST assume that the peer is incapable of receiving VCCV and MUST NOT send any OAM control channel traffic to it.
VCCV Capability AVPが全く合図されないなら、LCCE MUSTは、同輩がVCCVを受けることができないで、少しのOAMコントロールチャンネルトラフィックもそれに送ってはいけないと仮定します。
Nadeau & Pignataro Standards Track [Page 18] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[18ページ]。
All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, and Vendor ID. The Vendor ID for the VCCV Capability AVP MUST be 0, indicating that this is an IETF-defined AVP. This AVP MAY be hidden (the H bit MAY be 0 or 1). The M bit for this AVP SHOULD be set to 0. The Length (before hiding) of this AVP is 8.
すべてのL2TP AVPsには、M(義務的な)ビット、H(隠される)ビット、Length、およびVendor IDがあります。 これがIETFによって定義されたAVPであることを示して、VCCV Capability AVPのためのVendor IDは0であるに違いありません。 このAVP MAY、隠されてください(Hビットは、0か1であるかもしれません)。 MはこのAVP SHOULDのために噛み付きました。0に設定されます。 このAVPのLength(隠れることの前の)は8歳です。
7. Capability Advertisement Selection
7. 能力広告選択
When a PE receives a VCCV capability advertisement, the advertisement may potentially contain more than one CC or CV Type. Only matching capabilities can be selected. When multiple capabilities match, only one CC Type MUST be used.
PEがVCCV能力広告を受け取るとき、広告は潜在的に1CCかCV Typeを含むかもしれません。 合っている能力しか選択できません。 複数の能力が合っていると、1CC Typeだけを使用しなければなりません。
In particular, as already specified, once a valid CC Type is used by a PE (traffic sent using that encapsulation), the PE MUST NOT send any traffic down another CC Type control channel.
有効なCC TypeがPEによっていったん使用されると(トラフィックはそのカプセル化を使用することで発信しました)、特に、PE MUST NOTは既に指定されるように別のCC Type制御チャンネルの下側にどんなトラフィックも送ります。
For cases where multiple CC Types are advertised, the following precedence rules apply when choosing the single CC Type to use:
独身のCC Typeを選ぶとき、複数のCC Typesが広告に掲載されているケースの、以下の先行規則は使用に適用されます:
1. Type 1: PWE3 Control Word with 0001b as first nibble
1. タイプ1: 最初の少量としての0001bがあるPWE3 Control Word
2. Type 2: MPLS Router Alert Label
2. 2はタイプします: MPLSルータ警戒ラベル
3. Type 3: MPLS PW Label with TTL == 1
3. 3はタイプします: MPLS PWはTTLで1と=をラベルします。
For MPLS PWs, the CV Type of LSP Ping (0x02) is the default, and the CV Type of ICMP Ping (0x01) is optional.
MPLS PWsに関しては、LSP Ping(0×02)のCV Typeはデフォルトです、そして、ICMP Ping(0×01)のCV Typeは任意です。
8. IANA Considerations
8. IANA問題
8.1. VCCV Interface Parameters Sub-TLV
8.1. VCCVインタフェース・パラメータサブTLV
The VCCV Interface Parameters Sub-TLV codepoint is defined in [RFC4446]. IANA has created and will maintain registries for the CC Types and CV Types (bitmasks in the VCCV Parameter ID). The CC Type and CV Type new registries (see Sections 8.1.1 and 8.1.2, respectively) have been created in the Pseudo Wires Name Spaces, reachable from [IANA.pwe3-parameters]. The allocations must be done using the "IETF Consensus" policy defined in [RFC2434].
VCCV Interface Parameters Sub-TLV codepointは[RFC4446]で定義されます。 IANAは、作成して、CC TypesとCV Types(VCCV Parameter IDのビットマスク)のために登録であると主張するでしょう。 CC TypeとCV Typeの新しい登録、(セクション8.1 .1と8.1を見てください、.2 それぞれ)、Pseudo Wires Name Spacesで作成されてください、そうした、[IANA.pwe3-パラメタ]から、届きます。 [RFC2434]で定義された「IETFコンセンサス」方針を使用し配分を終わらなければなりません。
8.1.1. MPLS VCCV Control Channel (CC) Types
8.1.1. MPLS VCCV制御チャンネル(CC)はタイプします。
IANA has set up a registry of "MPLS VCCV Control Channel Types". These are 8 bitfields. CC Type values 0x01, 0x02, and 0x04 are specified in Section 4 of this document. The remaining bitfield values (0x08, 0x10, 0x20, 0x40, and 0x80) are to be assigned by IANA using the "IETF Consensus" policy defined in [RFC2434]. A VCCV
IANAは「MPLS VCCVコントロールチャンネル種別」の登録をセットアップしました。 これらは8bitfieldsです。 CC Type値0×01、0×02、および0x04はこのドキュメントのセクション4で指定されます。 残っているbitfield値(0×08、0×10、0×20、0×40、および0×80)は[RFC2434]で定義された「IETFコンセンサス」方針を使用することでIANAによって割り当てられることです。 VCCV
Nadeau & Pignataro Standards Track [Page 19] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[19ページ]。
Control Channel Type description and a reference to an RFC approved by the IESG are required for any assignment from this registry.
IESGによって承認されたRFCのコントロールChannel Type記述と参照がどんな課題にもこの登録から必要です。
MPLS Control Channel (CC) Types:
MPLS制御チャンネル(CC)はタイプします:
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - Type 1: PWE3 Control Word with 0001b as
first nibble (PW-ACH, see [RFC4385])
Bit 1 (0x02) - Type 2: MPLS Router Alert Label
Bit 2 (0x04) - Type 3: MPLS PW Label with TTL == 1
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
ビット(値)記述============ ========================================== ビット0(0×01)--1をタイプしてください: 最初に、少量(PW-ACH、[RFC4385]を見る)ビット1(0×02)としての0001bがあるPWE3 Control Word--2はタイプします: MPLSルータ警戒ラベルビット2(0×04)--3はタイプします: MPLS PWは予約される1TTL=ビット3(0×08)(予約されたビット4(0×10))で(0×20)とビット5をラベルします--(0×40)(予約されたビット7(0×80))が予約したビット6を予約します。
The most significant (high order) bit is labeled Bit 7, and the least significant (low order) bit is labeled Bit 0, see parenthetical "Value".
最も重要な(高位)ビットはBit7とラベルされます、そして、最も重要でない(下位)ビットはBit0とラベルされます、そして、挿入句の「値」を見てください。
8.1.2. MPLS VCCV Connectivity Verification (CV) Types
8.1.2. MPLS VCCV接続性検証(CV)はタイプします。
IANA has set up a registry of "MPLS VCCV Control Verification Types". These are 8 bitfields. CV Type values 0x01 and 0x02 are specified in Section 4 of this document. The remaining bitfield values (0x04, 0x08, 0x10, 0x20, 0x40, and 0x80) are to be assigned by IANA using the "IETF Consensus" policy defined in [RFC2434]. A VCCV Control Verification Type description and a reference to an RFC approved by the IESG are required for any assignment from this registry.
IANAは「MPLS VCCVコントロール検証タイプ」の登録をセットアップしました。 これらは8bitfieldsです。 CV Type値0×01と0x02はこのドキュメントのセクション4で指定されます。 残っているbitfield値(0×04、0×08、0×10、0×20、0×40、および0×80)は[RFC2434]で定義された「IETFコンセンサス」方針を使用することでIANAによって割り当てられることです。 IESGによって承認されたRFCのVCCV Control Verification Type記述と参照がどんな課題にもこの登録から必要です。
MPLS Connectivity Verification (CV) Types:
MPLS接続性検証(CV)はタイプします:
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - ICMP Ping
Bit 1 (0x02) - LSP Ping
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
ビット(値)記述============ ========================================== ICMPはビット1(0×02)を確認します--LSPピングビット2(0×04)(予約されたビット3(0×08))がビット4(0×10)を予約したというビット0(0×01)はビット5(0×20)を予約しました--(0×40)(予約されたビット7(0×80))が予約したビット6を予約します。
The most significant (high order) bit is labeled Bit 7, and the least significant (low order) bit is labeled Bit 0, see parenthetical "Value".
最も重要な(高位)ビットはBit7とラベルされます、そして、最も重要でない(下位)ビットはBit0とラベルされます、そして、挿入句の「値」を見てください。
Nadeau & Pignataro Standards Track [Page 20] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[20ページ]。
8.2. PW Associated Channel Type
8.2. PWの関連チャンネルタイプ
The PW Associated Channel Types used by VCCV as defined in Sections 5.1.1 and 6.1 rely on previously allocated numbers from the Pseudowire Associated Channel Types Registry [RFC4385] in the Pseudo Wires Name Spaces reachable from [IANA.pwe3-parameters]. In particular, 0x21 (Internet Protocol version 4) MUST be used whenever an IPv4 payload follows the Pseudowire Associated Channel Header, or 0x57 MUST be used when an IPv6 payload follows the Pseudowire Associated Channel Header.
セクション5.1.1と6.1で定義されるようにVCCVによって使用されたPW Associated Channel Typesは[IANA.pwe3-パラメタ]から届いているPseudo Wires Name SpacesのPseudowire Associated Channel Types Registry[RFC4385]から以前に割り当てられた数を当てにします。 IPv6ペイロードがPseudowire Associated Channel Headerに続くとき、IPv4ペイロードがPseudowire Associated Channel Headerに続くときはいつも、特に、0×21(インターネットプロトコルバージョン4)を使用しなければなりませんか、または0×57を使用しなければなりません。
8.3. L2TPv3 Assignments
8.3. L2TPv3課題
Section 8.3.1 through Section 8.3.3 are registrations of new L2TP values for registries already managed by IANA. Section 8.3.4 is a new registry that has been added to the existing L2TP name spaces, and will be maintained by IANA accordingly. The Layer Two Tunneling Protocol "L2TP" Name Spaces are reachable from [IANA.l2tp-parameters].
セクション8.3.3を通したセクション8.3.1はIANAによって既に管理された登録への新しいL2TP値の登録証明書です。 セクション8.3.4は空間という既存のL2TP名に追加されて、IANAによってそれに従って、維持される新しい登録です。 Layer Two Tunnelingプロトコル"L2TP"名前空間は[IANA.l2tp-パラメタ]から届いています。
8.3.1. Control Message Attribute Value Pairs (AVPs)
8.3.1. コントロールメッセージ属性値ペア(AVPs)
An additional AVP Attribute is specified in Section 6.3.1. It was defined by IANA as described in Section 2.2 of [RFC3438].
追加AVP Attributeはセクション6.3.1で指定されます。 それは[RFC3438]のセクション2.2で説明されるIANAによって定義されました。
Attribute
Type Description
--------- ----------------------------------
96 VCCV Capability AVP
属性タイプ記述--------- ---------------------------------- 96 VCCV能力AVP
8.3.2. Default L2-Specific Sublayer Bits
8.3.2. デフォルトL2特有の副層ビット
The Default L2-Specific Sublayer contains 8 bits in the low-order portion of the header. This document defines one reserved bit in the Default L2-Specific Sublayer in Section 6.1, which was assigned by IANA following IETF Consensus [RFC2434].
Default L2特有のSublayerはヘッダーの下位の一部に8ビットを含んでいます。 このドキュメントはセクション6.1でDefault L2特有のSublayerで予約された1ビットを定義します。(それは、IANAの次のIETF Consensus[RFC2434]によって割り当てられました)。
Default L2-Specific Sublayer bits - per [RFC3931]
---------------------------------
Bit 0 - V (VCCV) bit
[RFC3931]あたりのデフォルトL2特有のSublayerビット--------------------------------- ビット0--V(VCCV)に噛み付きました。
8.3.3. ATM-Specific Sublayer Bits
8.3.3. 気圧特有の副層ビット
The ATM-Specific Sublayer contains 8 bits in the low-order portion of the header. This document defines one reserved bit in the ATM- Specific Sublayer in Section 6.1, which was assigned by IANA following IETF Consensus [RFC2434].
ATM特有のSublayerはヘッダーの下位の一部に8ビットを含んでいます。 このドキュメントはセクション6.1でATMの特定のSublayerで予約された1ビットを定義します。(それは、IANAの次のIETF Consensus[RFC2434]によって割り当てられました)。
Nadeau & Pignataro Standards Track [Page 21] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[21ページ]。
ATM-Specific Sublayer bits - per [RFC4454]
--------------------------
Bit 0 - V (VCCV) bit
[RFC4454]あたりのATM特有のSublayerビット-------------------------- ビット0--V(VCCV)に噛み付きました。
8.3.4. VCCV Capability AVP Values
8.3.4. VCCV能力AVP値
This is a new registry that IANA maintains in the L2TP Name Spaces.
これはIANAがL2TP Name Spacesで維持する新しい登録です。
IANA created and maintains a registry for the CC Types and CV Types bitmasks in the VCCV Capability AVP, defined in Section 6.3.1. The allocations must be done using the "IETF Consensus" policy defined in [RFC2434]. A VCCV CC or CV Type description and a reference to an RFC approved by the IESG are required for any assignment from this registry.
IANAはセクション6.3.1で定義されたVCCV Capability AVPのCC TypesとCV Typesビットマスクのために登録を作成して、維持します。 [RFC2434]で定義された「IETFコンセンサス」方針を使用し配分を終わらなければなりません。 IESGによって承認されたRFCのVCCV CCかCV Type記述と参照がどんな課題にもこの登録から必要です。
IANA has reserved the following bits in this registry:
IANAはこの登録で以下のビットを予約しました:
VCCV Capability AVP (Attribute Type 96) Values
---------------------------------------------------
VCCV能力AVP(属性タイプ96)値---------------------------------------------------
L2TPv3 Control Channel (CC) Types:
L2TPv3制御チャンネル(CC)はタイプします:
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - L2-Specific Sublayer with V-bit set
Bit 1 (0x02) - Reserved
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
ビット(値)記述============ ========================================== ビット0(0×01)--V-ビットセットBit1(0×02)とL2特有のSublayer--予約されたBit2(0×04)(予約されたBit3(0×08))は予約されたBit6(0×40)(予約されたBit7(0×80))が予約したBit4(0×10)(予約されたBit5(0×20))を予約しました。
L2TPv3 Connectivity Verification (CV) Types:
L2TPv3接続性検証(CV)はタイプします:
Bit (Value) Description
============ ==========================================
Bit 0 (0x01) - ICMP Ping
Bit 1 (0x02) - Reserved
Bit 2 (0x04) - Reserved
Bit 3 (0x08) - Reserved
Bit 4 (0x10) - Reserved
Bit 5 (0x20) - Reserved
Bit 6 (0x40) - Reserved
Bit 7 (0x80) - Reserved
ビット(値)記述============ ========================================== ビット0(0×01)--ICMPピングビット1(0×02)(予約されたビット2(0×04))はビット3(0×08)を予約しました--予約されたビット4(0×10)(予約されたビット5(0×20))は(0×40)(予約されたビット7(0×80))が予約したビット6を予約しました。
Nadeau & Pignataro Standards Track [Page 22] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[22ページ]。
The most significant (high order) bit is labeled Bit 7, and the least significant (low order) bit is labeled Bit 0, see parenthetical "Value".
最も重要な(高位)ビットはBit7とラベルされます、そして、最も重要でない(下位)ビットはBit0とラベルされます、そして、挿入句の「値」を見てください。
9. Congestion Considerations
9. 混雑問題
The bandwidth resources used by VCCV are recommended to be minimal compared to those of the associated PW. The bandwidth required for the VCCV channel is taken outside any allocation for PW data traffic, and can be configurable. When doing resource reservation or network planning, the bandwidth requirements for both PW data and VCCV traffic need to be taken into account.
関連PWのものと比べて、VCCVによって使用された帯域幅リソースが最小量であることが推薦されます。 VCCVチャンネルに必要である帯域幅は、PWデータ通信量のためのどんな配分の外でも取られて、構成可能である場合があります。 資源予約かネットワーク計画をするとき、PWデータとVCCV交通の両方のための帯域幅要件は、考慮に入れられる必要があります。
VCCV applications (i.e., Connectivity Verification (CV) Types) MUST consider congestion and bandwidth usage implications and provide details on bandwidth or packet frequency management. VCCV applications can have built-in bandwidth management in their protocols. Other VCCV applications can have their bandwidth configuration-limited, and rate-limiting them can be harmful as it could translate to incorrectly declaring connectivity failures. For all other VCCV applications, outgoing VCCV messages SHOULD be rate- limited to prevent aggressive connectivity verification consuming excessive bandwidth, causing congestion, becoming denial-of-service attacks, or generating an excessive packet rate at the CE-bound PE.
VCCVアプリケーション(すなわち、Connectivity Verification(CV)はタイプする)は、混雑と帯域幅用法が含意であると考えて、帯域幅に関する詳細かパケット頻度管理を前提としなければなりません。 VCCVアプリケーションはそれらのプロトコルにおける内蔵の帯域幅管理を持つことができます。 他のVCCVアプリケーションでそれらの帯域幅は構成で有限になる場合があります、そして、それらをレートで制限するのは、不当に接続性失敗を宣言するのに翻訳できたので、有害である場合があります。 他のすべてのVCCVに関しては、アプリケーション、サービス不能攻撃になって、攻撃的な接続性検証が過度の帯域幅を消費するのを防ぐために制限されたレート、混雑を引き起こすことである出発しているVCCVメッセージSHOULDまたは過度のパケットを発生させるのがCE行きのPEで評価します。
If these conditions cannot be followed, an adaptive loss-based scheme SHOULD be applied to congestion-control outgoing VCCV traffic, so that it competes fairly with TCP within an order of magnitude. One method of determining an acceptable bandwidth for VCCV is described in [RFC3448] (TFRC); other methods exist. For example, bandwidth or packet frequency management can include any of the following: a negotiation of transmission interval/rate, a throttled transmission rate on "congestion detected" situations, a slow-start after shutdown due to congestion and until basic connectivity is verified, and other mechanisms.
これらの状態であるなら続くことができません、適応型の損失ベースの計画SHOULD。輻輳制御の外向的なVCCV交通に適用されてください、1桁以内でTCPと公正に競争するように。 VCCVのために許容できる帯域幅を決定する1つの方法が[RFC3448](TFRC)で説明されます。 他の方法は存在しています。 例えば、帯域幅かパケット頻度経営者側が以下のどれかを含むことができます: トランスミッション間隔/率の交渉、「検出された混雑」状況に関する阻止された通信速度、混雑による閉鎖の後と基本の接続性までの遅れた出発は確かめられて、他のメカニズムです。
The ICMP and MPLS LSP PING applications SHOULD be rate-limited to below 5% of the bit-rate of the associated PW. For this purpose, the considered bit-rate of a pseudowire is dependent on the PW type. For pseudowires that carry constant bit-rate traffic (e.g., TDM PWs) the full bit-rate of the PW is used. For pseudowires that carry variable bit-rate traffic (e.g., Ethernet PWs), the mean or sustained bit-rate of the PW is used.
ICMPとMPLS LSP PINGアプリケーションSHOULDはレートによって関連PWのビット伝送速度の5%未満に限られます。 このために、pseudowireの考えられたビット伝送速度はPWタイプに依存しています。 一定のビット伝送速度交通(例えば、TDM PWs)を運ぶpseudowiresに関しては、PWの完全なビット伝送速度は使用されています。 変化するビット伝送速度交通(例えば、イーサネットPWs)を運ぶpseudowiresに関しては、PWの意地悪であるか持続しているビット伝送速度は使用されています。
Nadeau & Pignataro Standards Track [Page 23] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[23ページ]。
As described in Section 10, incoming VCCV messages can be rate- limited as a protection against denial-of-service attacks. This throttling or policing of incoming VCCV messages should not be more stringent than the bandwidth allocated to the VCCV channel to prevent false indications of connectivity failure.
セクション10で説明されるように、入って来るVCCVメッセージはサービス不能攻撃に対する保護として制限されたレートであるかもしれません。 入って来るVCCVメッセージのこの阻止か取り締まりが接続性失敗の誤ったしるしを防ぐためにVCCVチャンネルに割り当てられた帯域幅より厳しいはずがありません。
10. Security Considerations
10. セキュリティ問題
Routers that implement VCCV create a Control Channel (CC) associated with a pseudowire. This control channel can be signaled (e.g., using LDP or L2TPv3 depending on the PWE3) or statically configured. Over this control channel, VCCV Connectivity Verification (CV) messages are sent. Therefore, three different areas are of concern from a security standpoint.
VCCVを実行するルータがpseudowireに関連づけられたControl Channel(CC)を作成します。 この制御チャンネルを合図するか(例えば、PWE3による自由民主党かL2TPv3を使用します)、または静的に構成できます。 この制御チャンネルの上に、VCCV Connectivity Verification(CV)メッセージを送ります。 したがって、3つのセキュリティ見地と異なった領域が重要です。
The first area of concern relates to control plane parameter and status message attacks, that is, attacks that concern the signaling of VCCV capabilities. MPLS PW Control Plane security is discussed in Section 8.2 of [RFC4447]. L2TPv3 PW Control Plane security is discussed in Section 8.1 of [RFC3931]. The addition of the connectivity verification negotiation extensions does not change the security aspects of Section 8.2 of [RFC4447], or Section 8.1 of [RFC3931]. Implementation of IP source address filters may also aid in deterring these types of attacks.
最初の気になる所はコントロール飛行機パラメタとステータスメッセージ攻撃(すなわち、VCCV能力のシグナリングに関する攻撃)に関連します。 [RFC4447]のセクション8.2でMPLS PW Control Planeセキュリティについて議論します。 [RFC3931]のセクション8.1でL2TPv3 PW Control Planeセキュリティについて議論します。 接続性検証交渉拡張子の添加は[RFC4447]のセクション8.2、または[RFC3931]のセクション8.1のセキュリティ局面を変えません。 また、IPソースアドレスフィルタの実現はこれらのタイプの攻撃を思いとどまらせる際に支援されるかもしれません。
A second area of concern centers on data-plane attacks, that is, attacks on the associated channel itself. Routers that implement the VCCV mechanisms are subject to additional data-plane denial-of- service attacks as follows:
2番目の気になる所はすなわち、データ飛行機攻撃、関連チャンネル自体に対する攻撃に集中します。 VCCVメカニズムを実行するルータは追加データ飛行機否定を受けることがある、-、-サービスは以下の通り攻撃されます:
An intruder could intercept or inject VCCV packets effectively
providing false positives or false negatives.
侵入者は、事実上、無病誤診か有病誤診を提供しながら、VCCVパケットを妨害するか、または注入できました。
An intruder could deliberately flood a peer router with VCCV
messages to deny services to others.
侵入者は故意に他のものに対するサービスを否定するVCCVメッセージで同輩ルータをあふれさせることができました。
A misconfigured or misbehaving device could inadvertently flood a
peer router with VCCV messages which could result in denial of
services. In particular, if a router has either implicitly or
explicitly indicated that it cannot support one or all of the
types of VCCV, but is sent those messages in sufficient quantity,
it could result in a denial of service.
misconfiguredされるかふらちな事する装置はサービスの否定をもたらすことができたVCCVメッセージで同輩ルータをうっかりあふれさせるかもしれません。 ルータが、1かVCCVのタイプを皆、支持できませんが、それらのメッセージが十分な数量に送られるのをそれとなくか明らかに示したなら、特に、それはサービスの否定をもたらすかもしれません。
To protect against these potential (deliberate or unintentional) attacks, multiple mitigation techniques can be employed:
これらの潜在的(慎重であるか意図的でない)の攻撃から守るために、複数の緩和のテクニックを使うことができます:
VCCV message throttling mechanisms can be used, especially in
distributed implementations which have a centralized control-plane
特に集中制御飛行機を持っている分配された実現にメカニズムを阻止するVCCVメッセージは使用できます。
Nadeau & Pignataro Standards Track [Page 24] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[24ページ]。
processor with various line cards attached by some control-plane
data path. In these architectures, VCCV messages may be processed
on the central processor after being forwarded there by the
receiving line card. In this case, the path between the line card
and the control processor may become saturated if appropriate VCCV
traffic throttling is not employed, which could lead to a complete
denial of service to users of the particular line card. Such
filtering is also useful for preventing the processing of unwanted
VCCV messages, such as those which are sent on unwanted (and
perhaps unadvertised) control channel types or VCCV types.
様々な線カードがあるプロセッサは何らかの制御飛行機データ経路のそばで付きました。 これらの構造では、VCCVメッセージは受信線カードでそこに送った後に、中央のプロセッサに処理されるかもしれません。 この場合、適切なVCCV交通阻止が採用していないなら、線カードと制御プロセッサの間の経路は飽和するようになるかもしれません(完全な特定の線カードのユーザに対するサービスの否定に通じることができました)。 また、そのようなフィルタリングが求められていなくて(恐らく「非-広告を出」します)のコントロールチャンネル種別で送られるものなどの求められていないVCCVメッセージの処理を防ぐことの役に立つか、またはVCCVはタイプします。
Section 8.1 of [RFC4447] discusses methods to protect the data
plane of MPLS PWs from data-plane attacks. However the
implementation of the connectivity verification protocol expands
the range of possible data-plane attacks. For this reason
implementations MUST provide a method to secure the data plane.
This can be in the form of encryption of the data by running IPsec
on MPLS packets encapsulated according to [RFC4023], or by
providing the ability to architect the MPLS network in such a way
that no external MPLS packets can be injected (private MPLS
network).
[RFC4447]のセクション8.1はデータ飛行機攻撃からMPLS PWsのデータ飛行機を保護する方法を論じます。 しかしながら、接続性査察協定の実現は可能なデータ飛行機攻撃の範囲を広くします。 この理由で、実現はデータ飛行機を固定する方法を提供しなければなりません。 これは、データの暗号化の形に[RFC4023]に応じてカプセルに入れられたMPLSパケットの上でIPsecを走らせるか、またはどんな外部のMPLSパケットも注入できないような方法(私設のMPLSネットワーク)でMPLSネットワークを建築家への能力に提供することによって、あることができます。
For L2TPv3, data packet spoofing considerations are outlined in
Section 8.2 of [RFC3931]. While the L2TPv3 Session ID provides
traffic separation, the optional Cookie field provides additional
protection to thwart spoofing attacks. To maximize protection
against a variety of data-plane attacks, a 64-bit Cookie can be
used. L2TPv3 can also be run over IPsec as detailed in Section
4.1.3 of [RFC3931].
L2TPv3に関しては、データ・パケットスプーフィング問題は[RFC3931]のセクション8.2に概説されています。 L2TPv3 Session IDは交通分離を提供しますが、任意のCookie分野は、スプーフィング攻撃を阻むために追加保護を提供します。 さまざまなデータ飛行機攻撃に対する保護を最大にするために、64ビットのCookieを使用できます。 また、L2TPv3は.3セクション4.1[RFC3931]で詳しく述べられるようにIPsecの上を走ることができます。
A third and last area of concern relates to the processing of the actual contents of VCCV messages, i.e., LSP Ping and ICMP messages. Therefore, the corresponding security considerations for these protocols (LSP Ping [RFC4379], ICMPv4 Ping [RFC0792], and ICMPv6 Ping [RFC4443]) apply as well.
3番目と最後の気になる所はすなわち、VCCVメッセージ、LSP PingとICMPメッセージの実際のコンテンツの処理に関連します。 したがって、また、これらのプロトコル(LSP Ping[RFC4379]、ICMPv4 Ping[RFC0792]、およびICMPv6 Ping[RFC4443])のための対応するセキュリティ問題は適用されます。
11. Acknowledgements
11. 承認
The authors would like to thank Hari Rakotoranto, Michel Khouderchah, Bertrand Duvivier, Vanson Lim, Chris Metz, W. Mark Townsley, Eric Rosen, Dan Tappan, Danny McPherson, Luca Martini, Don O'Connor, Neil Harrison, Danny Prairie, Mustapha Aissaoui, and Vasile Radoaca for their valuable comments and suggestions.
作者は彼らの貴重なコメントと提案についてハーリRakotoranto、ミシェルKhouderchah、バートランド・デュビビエ、Vansonリム、クリス・メス、W.マークTownsley、エリック・ローゼン、ダン・タッパン、ダニーMcPherson、ルカMartini、ドン・オコナー、ニール・ハリソン、ダニーPrairie、Mustapha Aissaoui、およびバシレRadoacaに感謝したがっています。
Nadeau & Pignataro Standards Track [Page 25] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[25ページ]。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC0792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
[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月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3032] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] ラウ、J.、Townsley、M.、およびI.Goyret、「2トンネリングプロトコルを層にしてください--バージョン3(L2TPv3)」、RFC3931、3月2005日
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC4379] Kompella、K.、およびG.は2006年2月に「マルチプロトコルのラベルの切り換えられた(MPLS)データ飛行機の故障を検出すること」でのRFC4379を飲み込みます。
[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson,
"Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
Use over an MPLS PSN", RFC 4385, February 2006.
[RFC4385] ブライアント、S.は飲み込まれます、マティーニ、L.とD.マクファーソン、「縁から縁(PWE3)へのコントロールがMPLS PSNの上の使用のために言い表すPseudowireエミュレーション」RFC4385、G.、2006年2月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] コンタ、A.、デアリング、S.、およびM.グプタ、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC4443、2006年3月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge
Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] マティーニ、L.、「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進む」BCP116、RFC4446、2006年4月。
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4447] マティーニ、L.、ローゼン、E.、高架鉄道-Aawar、N.、スミス、T.、およびG.サギ、「ラベル分配を使用するPseudowireセットアップと維持が(自由民主党)について議定書の中で述べます」、RFC4447、2006年4月。
12.2. Informative References
12.2. 有益な参照
[IANA.l2tp-parameters]
Internet Assigned Numbers Authority, "Layer Two Tunneling
Protocol "L2TP"", April 2007,
<http://www.iana.org/assignments/l2tp-parameters>.
[IANA.l2tp-パラメタ] インターネットは数の権威、「層Twoのトンネリングプロトコル"L2TP"」、2007年4月、<l2tp http://www.iana.org/課題/パラメタ>を割り当てました。
[IANA.pwe3-parameters]
Internet Assigned Numbers Authority, "Pseudo Wires Name
Spaces", June 2007,
<http://www.iana.org/assignments/pwe3-parameters>.
[IANA.pwe3-パラメタ] インターネットは数の権威、「疑似ワイヤ名前空間」、2007年6月、<pwe3http://www.iana.org/課題/パラメタ>を割り当てました。
Nadeau & Pignataro Standards Track [Page 26] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[26ページ]。
[MSG-MAP] Nadeau, T., "Pseudo Wire (PW) OAM Message Mapping",
Work in Progress, March 2007.
[MSG-地図] ナドー、T.、「疑似ワイヤ(PW)OAMメッセージマッピング」が進歩、2007年3月に働いています。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP)
Internet Assigned Numbers Authority (IANA) Considerations
Update", BCP 68, RFC 3438, December 2002.
w.[RFC3438]Townsley、「層Twoのトンネリングプロトコル(L2TP)インターネットは問題がアップデートする数の権威(IANA)を割り当てました」、BCP68、RFC3438、2002年12月。
[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 3448, January 2003.
[RFC3448] ハンドレー、M.、フロイド、S.、Padhye、J.、およびJ.ウィトマー、「TCPの好意的なレートは(TFRC)を制御します」。 「プロトコル仕様」、RFC3448、2003年1月。
[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for
Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916,
September 2004.
[RFC3916] Xiao、X.、マクファーソン、D.、およびP.頭、「疑似ワイヤエミュレーション縁から縁への(PWE3)のための要件」、RFC3916、2004年9月。
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] ブライアントとS.とP.頭、「疑似ワイヤエミュレーション縁から縁(PWE3)への構造」、RFC3985、2005年3月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)",
RFC 4023, March 2005.
[RFC4023] オースター、T.、Rekhter、Y.、およびE.ローゼン、「IPか一般ルーティングのカプセル化(GRE)でMPLSを要約します」、RFC4023(2005年3月)。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and S.
Matsushima, "Operations and Management (OAM) Requirements
for Multi-Protocol Label Switched (MPLS) Networks",
RFC 4377, February 2006.
[RFC4377] ナドー、T.、翌日、M.、ツバメ、G.、アラン、D.、およびS.松島、「マルチプロトコルのための要件がラベルする操作と経営者側(OAM)は(MPLS)ネットワークを切り換えました」、RFC4377、2006年2月。
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, April 2006.
[RFC4448] マティーニ、L.、ローゼン、E.、高架鉄道-Aawar、N.、およびG.サギ、「MPLSネットワークの上のイーサネットの輸送のためのカプセル化方法」、RFC4448(2006年4月)。
[RFC4454] Singh, S., Townsley, M., and C. Pignataro, "Asynchronous
Transfer Mode (ATM) over Layer 2 Tunneling Protocol
Version 3 (L2TPv3)", RFC 4454, May 2006.
[RFC4454]シン(S.、Townsley、M.、およびC.Pignataro、「層2のトンネリングプロトコルバージョン3(L2TPv3)の上の非同期通信モード(気圧)」、RFC4454)は、2006がそうするかもしれません。
[RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal
Cost Multipath Treatment in MPLS Networks", BCP 128,
RFC 4928, June 2007.
[RFC4928]のツバメ、G.、ブライアント、S.、およびL.アンデション、「同輩を避けるのはMPLSネットワークで多重通路処理かかりました」、BCP128、RFC4928、2007年6月。
Nadeau & Pignataro Standards Track [Page 27] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[27ページ]。
Appendix A. Contributors' Addresses
付録A.貢献者のアドレス
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
ビーバーブルック道路Boxborough、ジョージツバメシスコシステムズInc.300MA01719米国
EMail: swallow@cisco.com
メール: swallow@cisco.com
Monique Morrow Cisco Systems, Inc. Glatt-com CH-8301 Glattzentrum Switzerland
モニーク・翌日のシスコシステムズInc.グラット-com CH-8301 Glattzentrumスイス
EMail: mmorrow@cisco.com
メール: mmorrow@cisco.com
Yuichi Ikejiri NTT Communication Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 Shinjuku-ku JAPAN
Yuichi Ikejiri NTTコミュニケーション社1-1-6、内幸町、東京新宿区日本千代田区100-8019
EMail: y.ikejiri@ntt.com
メール: y.ikejiri@ntt.com
Kenji Kumaki KDDI Corporation KDDI Bldg. 2-3-2 Nishishinjuku Tokyo 163-8003 JAPAN
Kenji Kumaki KDDI社のKDDI Bldg. 2-3-2 Nishishinjuku日本東京163-8003
EMail: ke-kumaki@kddi.com
メール: ke-kumaki@kddi.com
Peter B. Busschbach Alcatel-Lucent 67 Whippany Road Whippany, NJ, 07981 USA
Roadウィッパニー、ピーターB.Busschbachアルカテル透明な67ウィッパニーニュージャージー07981米国
EMail: busschbach@alcatel-lucent.com
メール: busschbach@alcatel-lucent.com
Nadeau & Pignataro Standards Track [Page 28] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[28ページ]。
Rahul Aggarwal Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA 94089 USA
Rahul Aggarwal杜松は1194の北のマチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア94089米国
EMail: rahul@juniper.net
メール: rahul@juniper.net
Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 USA
ルカマティーニシスコシステムズ, Inc.9155のEastニコルズAvenue、スイート400イングルウッド、CO80112米国
EMail: lmartini@cisco.com
メール: lmartini@cisco.com
Authors' Addresses
作者のアドレス
Thomas D. Nadeau (editor) Cisco Systems, Inc. 300 Beaver Brook Road Boxborough, MA 01719 USA
Inc.300ビーバーブルック道路Boxborough、トーマスD.ナドー(エディタ)シスコシステムズMA01719米国
EMail: tnadeau@lucidvision.com
メール: tnadeau@lucidvision.com
Carlos Pignataro (editor) Cisco Systems, Inc. 7200 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 USA
カルロスPignataro(エディタ)シスコシステムズInc.7200キットクリーク道路私書箱14987リサーチトライアングル公園、NC27709米国
EMail: cpignata@cisco.com
メール: cpignata@cisco.com
Nadeau & Pignataro Standards Track [Page 29] RFC 5085 PW VCCV December 2007
ナドーとPignataro規格はPW VCCV2007年12月にRFC5085を追跡します[29ページ]。
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に情報を記述してください。
Nadeau & Pignataro Standards Track [Page 30]
ナドーとPignataro標準化過程[30ページ]
一覧
スポンサーリンク
