RFC3471 日本語訳
3471 Generalized Multi-Protocol Label Switching (GMPLS) SignalingFunctional Description. L. Berger, Ed.. January 2003. (Format: TXT=72105 bytes) (Updated by RFC4201, RFC4328, RFC4872) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Berger, Editor Request for Comments: 3471 Movaz Networks Category: Standards Track January 2003
Network Working Group L. Berger, Editor Request for Comments: 3471 Movaz Networks Category: Standards Track January 2003
Generalized Multi-Protocol Label Switching (GMPLS)
Signaling Functional Description
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description
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.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Abstract
This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents.
This document describes extensions to Multi-Protocol Label Switching (MPLS) signaling required to support Generalized MPLS. Generalized MPLS extends the MPLS control plane to encompass time-division (e.g., Synchronous Optical Network and Synchronous Digital Hierarchy, SONET/SDH), wavelength (optical lambdas) and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms, and technology specific details are specified in separate documents.
Table of Contents
Table of Contents
1. Introduction ............................................... 2
2. Overview .................................................. 3
3. Label Related Formats ..................................... 6
3.1 Generalized Label Request ............................... 6
3.2 Generalized Label ....................................... 11
3.3 Waveband Switching ...................................... 12
3.4 Suggested Label ......................................... 13
3.5 Label Set ............................................... 14
4. Bidirectional LSPs ......................................... 16
4.1 Required Information .................................... 17
4.2 Contention Resolution ................................... 17
5. Notification on Label Error ................................ 20
6. Explicit Label Control ..................................... 20
6.1 Required Information .................................... 21
1. Introduction ............................................... 2 2. Overview .................................................. 3 3. Label Related Formats ..................................... 6 3.1 Generalized Label Request ............................... 6 3.2 Generalized Label ....................................... 11 3.3 Waveband Switching ...................................... 12 3.4 Suggested Label ......................................... 13 3.5 Label Set ............................................... 14 4. Bidirectional LSPs ......................................... 16 4.1 Required Information .................................... 17 4.2 Contention Resolution ................................... 17 5. Notification on Label Error ................................ 20 6. Explicit Label Control ..................................... 20 6.1 Required Information .................................... 21
Berger Standards Track [Page 1] RFC 3471 GMPLS Signaling Functional Description
Berger Standards Track [Page 1] RFC 3471 GMPLS Signaling Functional Description
7. Protection Information ..................................... 21
7.1 Required Information .................................... 22
8. Administrative Status Information .......................... 23
8.1 Required Information .................................... 24
9. Control Channel Separation ................................. 25
9.1 Interface Identification ................................ 25
9.2 Fault Handling .......................................... 27
10. Acknowledgments ............................................ 27
11. Security Considerations .................................... 28
12. IANA Considerations ........................................ 28
13. Intellectual Property Considerations ....................... 29
14. References ................................................. 29
14.1 Normative References ................................... 29
14.2 Informative References ................................. 30
15. Contributors ............................................... 31
16. Editor's Address ........................................... 33
17. Full Copyright Statement ................................... 34
7. Protection Information ..................................... 21 7.1 Required Information .................................... 22 8. Administrative Status Information .......................... 23 8.1 Required Information .................................... 24 9. Control Channel Separation ................................. 25 9.1 Interface Identification ................................ 25 9.2 Fault Handling .......................................... 27 10. Acknowledgments ............................................ 27 11. Security Considerations .................................... 28 12. IANA Considerations ........................................ 28 13. Intellectual Property Considerations ....................... 29 14. References ................................................. 29 14.1 Normative References ................................... 29 14.2 Informative References ................................. 30 15. Contributors ............................................... 31 16. Editor's Address ........................................... 33 17. Full Copyright Statement ................................... 34
1. Introduction
1. Introduction
The Multiprotocol Label Switching (MPLS) architecture [RFC3031] has been defined to support the forwarding of data based on a label. In this architecture, Label Switching Routers (LSRs) were assumed to have a forwarding plane that is capable of (a) recognizing either packet or cell boundaries, and (b) being able to process either packet headers (for LSRs capable of recognizing packet boundaries) or cell headers (for LSRs capable of recognizing cell boundaries).
The Multiprotocol Label Switching (MPLS) architecture [RFC3031] has been defined to support the forwarding of data based on a label. In this architecture, Label Switching Routers (LSRs) were assumed to have a forwarding plane that is capable of (a) recognizing either packet or cell boundaries, and (b) being able to process either packet headers (for LSRs capable of recognizing packet boundaries) or cell headers (for LSRs capable of recognizing cell boundaries).
The original architecture has recently been extended to include LSRs whose forwarding plane recognizes neither packet, nor cell boundaries, and therefore, can't forward data based on the information carried in either packet or cell headers. Specifically, such LSRs include devices where the forwarding decision is based on time slots, wavelengths, or physical ports.
The original architecture has recently been extended to include LSRs whose forwarding plane recognizes neither packet, nor cell boundaries, and therefore, can't forward data based on the information carried in either packet or cell headers. Specifically, such LSRs include devices where the forwarding decision is based on time slots, wavelengths, or physical ports.
Given the above, LSRs, or more precisely interfaces on LSRs, can be subdivided into the following classes:
Given the above, LSRs, or more precisely interfaces on LSRs, can be subdivided into the following classes:
1. Interfaces that recognize packet/cell boundaries and can forward
data based on the content of the packet/cell header. Examples
include interfaces on routers that forward data based on the
content of the "shim" header, interfaces on (Asynchronous Transfer
Mode) ATM-LSRs that forward data based on the ATM VPI/VCI. Such
interfaces are referred to as Packet-Switch Capable (PSC).
1. Interfaces that recognize packet/cell boundaries and can forward data based on the content of the packet/cell header. Examples include interfaces on routers that forward data based on the content of the "shim" header, interfaces on (Asynchronous Transfer Mode) ATM-LSRs that forward data based on the ATM VPI/VCI. Such interfaces are referred to as Packet-Switch Capable (PSC).
Berger Standards Track [Page 2] RFC 3471 GMPLS Signaling Functional Description
Berger Standards Track [Page 2] RFC 3471 GMPLS Signaling Functional Description
2. Interfaces that forward data based on the data's time slot in a
repeating cycle. An example of such an interface is an interface
on a SONET/SDH Cross-Connect. Such interfaces are referred to as
Time-Division Multiplex Capable (TDM).
2. Interfaces that forward data based on the data's time slot in a repeating cycle. An example of such an interface is an interface on a SONET/SDH Cross-Connect. Such interfaces are referred to as Time-Division Multiplex Capable (TDM).
3. Interfaces that forward data based on the wavelength on which the
data is received. An example of such an interface is an interface
on an Optical Cross-Connect that can operate at the level of an
individual wavelength. Such interfaces are referred to as Lambda
Switch Capable (LSC).
3. Interfaces that forward data based on the wavelength on which the data is received. An example of such an interface is an interface on an Optical Cross-Connect that can operate at the level of an individual wavelength. Such interfaces are referred to as Lambda Switch Capable (LSC).
4. Interfaces that forward data based on a position of the data in
the real world physical spaces. An example of such an interface
is an interface on an Optical Cross-Connect that can operate at
the level of a single (or multiple) fibers. Such interfaces are
referred to as Fiber-Switch Capable (FSC).
4. Interfaces that forward data based on a position of the data in the real world physical spaces. An example of such an interface is an interface on an Optical Cross-Connect that can operate at the level of a single (or multiple) fibers. Such interfaces are referred to as Fiber-Switch Capable (FSC).
Using the concept of nested Label Switched Paths (LSPs) allows the system to scale by building a forwarding hierarchy. At the top of this hierarchy are FSC interfaces, followed by LSC interfaces, followed by TDM interfaces, followed by PSC interfaces. This way, an LSP that starts and ends on a PSC interface can be nested (together with other LSPs) into an LSP that starts and ends on a TDM interface. This LSP, in turn, can be nested (together with other LSPs) into an LSP that starts and ends on an LSC interface, which in turn can be nested (together with other LSPs) into an LSP that starts and ends on a FSC interface. See [MPLS-HIERARCHY] for more information on LSP hierarchies.
Using the concept of nested Label Switched Paths (LSPs) allows the system to scale by building a forwarding hierarchy. At the top of this hierarchy are FSC interfaces, followed by LSC interfaces, followed by TDM interfaces, followed by PSC interfaces. This way, an LSP that starts and ends on a PSC interface can be nested (together with other LSPs) into an LSP that starts and ends on a TDM interface. This LSP, in turn, can be nested (together with other LSPs) into an LSP that starts and ends on an LSC interface, which in turn can be nested (together with other LSPs) into an LSP that starts and ends on a FSC interface. See [MPLS-HIERARCHY] for more information on LSP hierarchies.
The establishment of LSPs that span only the first class of interfaces is defined in [RFC3036, RFC3212, RFC3209]. This document presents a functional description of the extensions needed to generalize the MPLS control plane to support each of the four classes of interfaces. Only signaling protocol independent formats and definitions are provided in this document. Protocol specific formats are defined in [RFC3473] and [RFC3472]. Technology specific details are outside the scope of this document and will be specified in technology specific documents, such as [GMPLS-SONET].
The establishment of LSPs that span only the first class of interfaces is defined in [RFC3036, RFC3212, RFC3209]. This document presents a functional description of the extensions needed to generalize the MPLS control plane to support each of the four classes of interfaces. Only signaling protocol independent formats and definitions are provided in this document. Protocol specific formats are defined in [RFC3473] and [RFC3472]. Technology specific details are outside the scope of this document and will be specified in technology specific documents, such as [GMPLS-SONET].
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. Overview
2. Overview
Generalized MPLS differs from traditional MPLS in that it supports multiple types of switching, i.e., the addition of support for TDM, lambda, and fiber (port) switching. The support for the additional
Generalized MPLS differs from traditional MPLS in that it supports multiple types of switching, i.e., the addition of support for TDM, lambda, and fiber (port) switching. The support for the additional
Berger Standards Track [Page 3] RFC 3471 GMPLS Signaling Functional Description
Berger Standards Track [Page 3] RFC 3471 GMPLS Signaling Functional Description
types of switching has driven generalized MPLS to extend certain base functions of traditional MPLS and, in some cases, to add functionality. These changes and additions impact basic LSP properties, how labels are requested and communicated, the unidirectional nature of LSPs, how errors are propagated, and information provided for synchronizing the ingress and egress.
types of switching has driven generalized MPLS to extend certain base functions of traditional MPLS and, in some cases, to add functionality. These changes and additions impact basic LSP properties, how labels are requested and communicated, the unidirectional nature of LSPs, how errors are propagated, and information provided for synchronizing the ingress and egress.
In traditional MPLS Traffic Engineering, links traversed by an LSP can include an intermix of links with heterogeneous label encodings. For example, an LSP may span links between routers, links between routers and ATM-LSRs, and links between ATM-LSRs. Generalized MPLS extends this by including links where the label is encoded as a time slot, or a wavelength, or a position in the real world physical space. Just like with traditional MPLS TE, where not all LSRs are capable of recognizing (IP) packet boundaries (e.g., an ATM-LSR) in their forwarding plane, generalized MPLS includes support for LSRs that can't recognize (IP) packet boundaries in their forwarding plane. In traditional MPLS TE an LSP that carries IP has to start and end on a router. Generalized MPLS extends this by requiring an LSP to start and end on similar type of LSRs. Also, in generalized MPLS the type of a payload that can be carried by an LSP is extended to allow such payloads as SONET/SDH, or 1 or 10Gb Ethernet. These changes from traditional MPLS are reflected in how labels are requested and communicated in generalized MPLS, see Sections 3.1 and 3.2. A special case of Lambda switching, called Waveband switching is also described in Section 3.3.
In traditional MPLS Traffic Engineering, links traversed by an LSP can include an intermix of links with heterogeneous label encodings. For example, an LSP may span links between routers, links between routers and ATM-LSRs, and links between ATM-LSRs. Generalized MPLS extends this by including links where the label is encoded as a time slot, or a wavelength, or a position in the real world physical space. Just like with traditional MPLS TE, where not all LSRs are capable of recognizing (IP) packet boundaries (e.g., an ATM-LSR) in their forwarding plane, generalized MPLS includes support for LSRs that can't recognize (IP) packet boundaries in their forwarding plane. In traditional MPLS TE an LSP that carries IP has to start and end on a router. Generalized MPLS extends this by requiring an LSP to start and end on similar type of LSRs. Also, in generalized MPLS the type of a payload that can be carried by an LSP is extended to allow such payloads as SONET/SDH, or 1 or 10Gb Ethernet. These changes from traditional MPLS are reflected in how labels are requested and communicated in generalized MPLS, see Sections 3.1 and 3.2. A special case of Lambda switching, called Waveband switching is also described in Section 3.3.
Another basic difference between traditional and non-PSC types of generalized MPLS LSPs, is that bandwidth allocation for an LSP can be performed only in discrete units, see Section 3.1.3. There are also likely to be (much) fewer labels on non-PSC links than on PSC links. Note that the use of Forwarding Adjacencies (FA), see [MPLS- HIERARCHY], provides a mechanism that may improve bandwidth utilization, when bandwidth allocation can be performed only in discrete units, as well as a mechanism to aggregate forwarding state, thus allowing the number of required labels to be reduced.
Another basic difference between traditional and non-PSC types of generalized MPLS LSPs, is that bandwidth allocation for an LSP can be performed only in discrete units, see Section 3.1.3. There are also likely to be (much) fewer labels on non-PSC links than on PSC links. Note that the use of Forwarding Adjacencies (FA), see [MPLS- HIERARCHY], provides a mechanism that may improve bandwidth utilization, when bandwidth allocation can be performed only in discrete units, as well as a mechanism to aggregate forwarding state, thus allowing the number of required labels to be reduced.
Generalized MPLS allows for a label to be suggested by an upstream node, see Section 3.4. This suggestion may be overridden by a downstream node but, in some cases, at the cost of higher LSP setup time. The suggested label is valuable when establishing LSPs through certain kinds of optical equipment where there may be a lengthy (in electrical terms) delay in configuring the switching fabric. For example micro mirrors may have to be elevated or moved, and this physical motion and subsequent damping takes time. If the labels and hence switching fabric are configured in the reverse direction (the
Generalized MPLS allows for a label to be suggested by an upstream node, see Section 3.4. This suggestion may be overridden by a downstream node but, in some cases, at the cost of higher LSP setup time. The suggested label is valuable when establishing LSPs through certain kinds of optical equipment where there may be a lengthy (in electrical terms) delay in configuring the switching fabric. For example micro mirrors may have to be elevated or moved, and this physical motion and subsequent damping takes time. If the labels and hence switching fabric are configured in the reverse direction (the
Berger Standards Track [Page 4] RFC 3471 GMPLS Signaling Functional Description
Berger Standards Track [Page 4] RFC 3471 GMPLS Signaling Functional Description
norm) the MAPPING/Resv message may need to be delayed by 10's of milliseconds per hop in order to establish a usable forwarding path. The suggested label is also valuable when recovering from nodal faults.
norm) the MAPPING/Resv message may need to be delayed by 10's of milliseconds per hop in order to establish a usable forwarding path. The suggested label is also valuable when recovering from nodal faults.
Generalized MPLS extends on the notion of restricting the range of labels that may be selected by a downstream node, see Section 3.5. In generalized MPLS, an ingress or other upstream node may restrict the labels that may be used by an LSP along either a single hop or along the whole LSP path. This feature is driven from the optical domain where there are cases where wavelengths used by the path must be restricted either to a small subset of possible wavelengths, or to one specific wavelength. This requirement occurs because some equipment may only be able to generate a small set of the wavelengths that intermediate equipment may be able to switch, or because intermediate equipment may not be able to switch a wavelength at all, being only able to redirect it to a different fiber.
Generalized MPLS extends on the notion of restricting the range of labels that may be selected by a downstream node, see Section 3.5. In generalized MPLS, an ingress or other upstream node may restrict the labels that may be used by an LSP along either a single hop or along the whole LSP path. This feature is driven from the optical domain where there are cases where wavelengths used by the path must be restricted either to a small subset of possible wavelengths, or to one specific wavelength. This requirement occurs because some equipment may only be able to generate a small set of the wavelengths that intermediate equipment may be able to switch, or because intermediate equipment may not be able to switch a wavelength at all, being only able to redirect it to a different fiber.
While traditional traffic engineered MPLS (and even LDP) are unidirectional, generalized MPLS supports the establishment of bidirectional LSPs, see Section 4. The need for bidirectional LSPs comes from non-PSC applications. There are multiple reasons why such LSPs are needed, particularly possible resource contention when allocating reciprocal LSPs via separate signaling sessions, and simplifying failure restoration procedures in the non-PSC case. Bidirectional LSPs also have the benefit of lower setup latency and lower number of messages required during setup.
While traditional traffic engineered MPLS (and even LDP) are unidirectional, generalized MPLS supports the establishment of bidirectional LSPs, see Section 4. The need for bidirectional LSPs comes from non-PSC applications. There are multiple reasons why such LSPs are needed, particularly possible resource contention when allocating reciprocal LSPs via separate signaling sessions, and simplifying failure restoration procedures in the non-PSC case. Bidirectional LSPs also have the benefit of lower setup latency and lower number of messages required during setup.
Generalized MPLS supports the communication of a specific label to use on a specific interface, see Section 6. [RFC3473] also supports an RSVP specific mechanism for rapid failure notification.
Generalized MPLS supports the communication of a specific label to use on a specific interface, see Section 6. [RFC3473] also supports an RSVP specific mechanism for rapid failure notification.
Generalized MPLS formalizes possible separation of control and data channels, see Section 9. Such support is particularly important to support technologies where control traffic cannot be sent in-band with the data traffic.
Generalized MPLS formalizes possible separation of control and data channels, see Section 9. Such support is particularly important to support technologies where control traffic cannot be sent in-band with the data traffic.
Generalized MPLS also allows for the inclusion of technology specific parameters in signaling. The intent is for all technology specific parameters to be carried, when using RSVP, in the SENDER_TSPEC and other related objects, and when using CR-LDP, in the Traffic Parameters TLV. Technology specific formats will be defined on an as needed basis. For an example definition, see [GMPLS-SONET].
Generalized MPLS also allows for the inclusion of technology specific parameters in signaling. The intent is for all technology specific parameters to be carried, when using RSVP, in the SENDER_TSPEC and other related objects, and when using CR-LDP, in the Traffic Parameters TLV. Technology specific formats will be defined on an as needed basis. For an example definition, see [GMPLS-SONET].
Berger Standards Track [Page 5] RFC 3471 GMPLS Signaling Functional Description
Berger Standards Track [Page 5] RFC 3471 GMPLS Signaling Functional Description
3. Label Related Formats
3. Label Related Formats
To deal with the widening scope of MPLS into the optical and time domain, several new forms of "label" are required. These new forms of label are collectively referred to as a "generalized label". A generalized label contains enough information to allow the receiving node to program its cross connect, regardless of the type of this cross connect, such that the ingress segments of the path are properly joined. This section defines a generalized label request, a generalized label, support for waveband switching, suggested label and label sets.
To deal with the widening scope of MPLS into the optical and time domain, several new forms of "label" are required. These new forms of label are collectively referred to as a "generalized label". A generalized label contains enough information to allow the receiving node to program its cross connect, regardless of the type of this cross connect, such that the ingress segments of the path are properly joined. This section defines a generalized label request, a generalized label, support for waveband switching, suggested label and label sets.
Note that since the nodes sending and receiving the new form of label know what kinds of link they are using, the generalized label does not contain a type field, instead the nodes are expected to know from context what type of label to expect.
Note that since the nodes sending and receiving the new form of label know what kinds of link they are using, the generalized label does not contain a type field, instead the nodes are expected to know from context what type of label to expect.
3.1. Generalized Label Request
3.1. Generalized Label Request
The Generalized Label Request supports communication of characteristics required to support the LSP being requested. These characteristics include LSP encoding and LSP payload. Note that these characteristics may be used by transit nodes, e.g., to support penultimate hop popping.
The Generalized Label Request supports communication of characteristics required to support the LSP being requested. These characteristics include LSP encoding and LSP payload. Note that these characteristics may be used by transit nodes, e.g., to support penultimate hop popping.
The Generalized Label Request carries an LSP encoding parameter, called LSP Encoding Type. This parameter indicates the encoding type, e.g., SONET/SDH/GigE etc., that will be used with the data associated with the LSP. The LSP Encoding Type represents the nature of the LSP, and not the nature of the links that the LSP traverses. A link may support a set of encoding formats, where support means that a link is able to carry and switch a signal of one or more of these encoding formats depending on the resource availability and capacity of the link. For example, consider an LSP signaled with "lambda" encoding. It is expected that such an LSP would be supported with no electrical conversion and no knowledge of the modulation and speed by the transit nodes. Other formats normally require framing knowledge, and field parameters are broken into the framing type and speed as shown below.
The Generalized Label Request carries an LSP encoding parameter, called LSP Encoding Type. This parameter indicates the encoding type, e.g., SONET/SDH/GigE etc., that will be used with the data associated with the LSP. The LSP Encoding Type represents the nature of the LSP, and not the nature of the links that the LSP traverses. A link may support a set of encoding formats, where support means that a link is able to carry and switch a signal of one or more of these encoding formats depending on the resource availability and capacity of the link. For example, consider an LSP signaled with "lambda" encoding. It is expected that such an LSP would be supported with no electrical conversion and no knowledge of the modulation and speed by the transit nodes. Other formats normally require framing knowledge, and field parameters are broken into the framing type and speed as shown below.
The Generalized Label Request also indicates the type of switching that is being requested on a link. This field normally is consistent across all links of an LSP.
The Generalized Label Request also indicates the type of switching that is being requested on a link. This field normally is consistent across all links of an LSP.
Berger Standards Track [Page 6] RFC 3471 GMPLS Signaling Functional Description
Berger Standards Track [Page 6] RFC 3471 GMPLS Signaling Functional Description
3.1.1. Required Information
3.1.1. Required Information
The information carried in a Generalized Label Request is:
The information carried in a Generalized Label Request is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type |Switching Type | G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP Encoding Type: 8 bits
LSP Encoding Type: 8 bits
Indicates the encoding of the LSP being requested. The
following shows permitted values and their meaning:
Indicates the encoding of the LSP being requested. The following shows permitted values and their meaning:
Value Type
----- ----
1 Packet
2 Ethernet
3 ANSI/ETSI PDH
4 Reserved
5 SDH ITU-T G.707 / SONET ANSI T1.105
6 Reserved
7 Digital Wrapper
8 Lambda (photonic)
9 Fiber
10 Reserved
11 FiberChannel
Value Type ----- ---- 1 Packet 2 Ethernet 3 ANSI/ETSI PDH 4 Reserved 5 SDH ITU-T G.707 / SONET ANSI T1.105 6 Reserved 7 Digital Wrapper 8 Lambda (photonic) 9 Fiber 10 Reserved 11 FiberChannel
The ANSI PDH and ETSI PDH types designate these respective
networking technologies. DS1 and DS3 are examples of ANSI PDH
LSPs. An E1 LSP would be ETSI PDH. The Lambda encoding type
refers to an LSP that encompasses a whole wavelengths. The
Fiber encoding type refers to an LSP that encompasses a whole
fiber port.
The ANSI PDH and ETSI PDH types designate these respective networking technologies. DS1 and DS3 are examples of ANSI PDH LSPs. An E1 LSP would be ETSI PDH. The Lambda encoding type refers to an LSP that encompasses a whole wavelengths. The Fiber encoding type refers to an LSP that encompasses a whole fiber port.
Berger Standards Track [Page 7] RFC 3471 GMPLS Signaling Functional Description
Berger Standards Track [Page 7] RFC 3471 GMPLS Signaling Functional Description
Switching Type: 8 bits
Switching Type: 8 bits
Indicates the type of switching that should be performed on a
particular link. This field is needed for links that advertise
more than one type of switching capability. This field should
map to one of the values advertised for the corresponding link
in the routing Switching Capability Descriptor, see [GMPLS-
RTG].
Indicates the type of switching that should be performed on a particular link. This field is needed for links that advertise more than one type of switching capability. This field should map to one of the values advertised for the corresponding link in the routing Switching Capability Descriptor, see [GMPLS- RTG].
The following are currently defined values:
The following are currently defined values:
Value Type
----- ----
1 Packet-Switch Capable-1 (PSC-1)
2 Packet-Switch Capable-2 (PSC-2)
3 Packet-Switch Capable-3 (PSC-3)
4 Packet-Switch Capable-4 (PSC-4)
51 Layer-2 Switch Capable (L2SC)
100 Time-Division-Multiplex Capable (TDM)
150 Lambda-Switch Capable (LSC)
200 Fiber-Switch Capable (FSC)
Value Type ----- ---- 1 Packet-Switch Capable-1 (PSC-1) 2 Packet-Switch Capable-2 (PSC-2) 3 Packet-Switch Capable-3 (PSC-3) 4 Packet-Switch Capable-4 (PSC-4) 51 Layer-2 Switch Capable (L2SC) 100 Time-Division-Multiplex Capable (TDM) 150 Lambda-Switch Capable (LSC) 200 Fiber-Switch Capable (FSC)
Berger Standards Track [Page 8] RFC 3471 GMPLS Signaling Functional Description
Berger Standards Track [Page 8] RFC 3471 GMPLS Signaling Functional Description
Generalized PID (G-PID): 16 bits
Generalized PID (G-PID): 16 bits
An identifier of the payload carried by an LSP, i.e., an
identifier of the client layer of that LSP. This is used by
the nodes at the endpoints of the LSP, and in some cases by the
penultimate hop. Standard Ethertype values are used for packet
and Ethernet LSPs; other values are:
An identifier of the payload carried by an LSP, i.e., an identifier of the client layer of that LSP. This is used by the nodes at the endpoints of the LSP, and in some cases by the penultimate hop. Standard Ethertype values are used for packet and Ethernet LSPs; other values are:
Value Type Technology
----- ---- ----------
0 Unknown All
1 Reserved
2 Reserved
3 Reserved
4 Reserved
5 Asynchronous mapping of E4 SDH
6 Asynchronous mapping of DS3/T3 SDH
7 Asynchronous mapping of E3 SDH
8 Bit synchronous mapping of E3 SDH
9 Byte synchronous mapping of E3 SDH
10 Asynchronous mapping of DS2/T2 SDH
11 Bit synchronous mapping of DS2/T2 SDH
12 Reserved
13 Asynchronous mapping of E1 SDH
14 Byte synchronous mapping of E1 SDH
15 Byte synchronous mapping of 31 * DS0 SDH
16 Asynchronous mapping of DS1/T1 SDH
17 Bit synchronous mapping of DS1/T1 SDH
18 Byte synchronous mapping of DS1/T1 SDH
19 VC-11 in VC-12 SDH
20 Reserved
21 Reserved
22 DS1 SF Asynchronous SONET
23 DS1 ESF Asynchronous SONET
24 DS3 M23 Asynchronous SONET
25 DS3 C-Bit Parity Asynchronous SONET
26 VT/LOVC SDH
27 STS SPE/HOVC SDH
28 POS - No Scrambling, 16 bit CRC SDH
29 POS - No Scrambling, 32 bit CRC SDH
30 POS - Scrambling, 16 bit CRC SDH
31 POS - Scrambling, 32 bit CRC SDH
32 ATM mapping SDH
33 Ethernet SDH, Lambda, Fiber
34 SONET/SDH Lambda, Fiber
35 Reserved (SONET deprecated) Lambda, Fiber
36 Digital Wrapper Lambda, Fiber
37 Lambda Fiber
Value Type Technology ----- ---- ---------- 0 Unknown All 1 Reserved 2 Reserved 3 Reserved 4 Reserved 5 Asynchronous mapping of E4 SDH 6 Asynchronous mapping of DS3/T3 SDH 7 Asynchronous mapping of E3 SDH 8 Bit synchronous mapping of E3 SDH 9 Byte synchronous mapping of E3 SDH 10 Asynchronous mapping of DS2/T2 SDH 11 Bit synchronous mapping of DS2/T2 SDH 12 Reserved 13 Asynchronous mapping of E1 SDH 14 Byte synchronous mapping of E1 SDH 15 Byte synchronous mapping of 31 * DS0 SDH 16 Asynchronous mapping of DS1/T1 SDH 17 Bit synchronous mapping of DS1/T1 SDH 18 Byte synchronous mapping of DS1/T1 SDH 19 VC-11 in VC-12 SDH 20 Reserved 21 Reserved 22 DS1 SF Asynchronous SONET 23 DS1 ESF Asynchronous SONET 24 DS3 M23 Asynchronous SONET 25 DS3 C-Bit Parity Asynchronous SONET 26 VT/LOVC SDH 27 STS SPE/HOVC SDH 28 POS - No Scrambling, 16 bit CRC SDH 29 POS - No Scrambling, 32 bit CRC SDH 30 POS - Scrambling, 16 bit CRC SDH 31 POS - Scrambling, 32 bit CRC SDH 32 ATM mapping SDH 33 Ethernet SDH, Lambda, Fiber 34 SONET/SDH Lambda, Fiber 35 Reserved (SONET deprecated) Lambda, Fiber 36 Digital Wrapper Lambda, Fiber 37 Lambda Fiber
Berger Standards Track [Page 9] RFC 3471 GMPLS Signaling Functional Description
Berger Standards Track [Page 9] RFC 3471 GMPLS Signaling Functional Description
38 ANSI/ETSI PDH SDH
39 Reserved SDH
40 Link Access Protocol SDH SDH
(LAPS - X.85 and X.86)
41 FDDI SDH, Lambda, Fiber
42 DQDB (ETSI ETS 300 216) SDH
43 FiberChannel-3 (Services) FiberChannel
44 HDLC SDH
45 Ethernet V2/DIX (only) SDH, Lambda, Fiber
46 Ethernet 802.3 (only) SDH, Lambda, Fiber
38 ANSI/ETSI PDH SDH 39 Reserved SDH 40 Link Access Protocol SDH SDH (LAPS - X.85 and X.86) 41 FDDI SDH, Lambda, Fiber 42 DQDB (ETSI ETS 300 216) SDH 43 FiberChannel-3 (Services) FiberChannel 44 HDLC SDH 45 Ethernet V2/DIX (only) SDH, Lambda, Fiber 46 Ethernet 802.3 (only) SDH, Lambda, Fiber
3.1.2. Bandwidth Encoding
3.1.2. Bandwidth Encoding
Bandwidth encodings are carried in 32 bit number in IEEE floating point format (the unit is bytes per second). For non-packet LSPs, it is useful to define discrete values to identify the bandwidth of the LSP. Some typical values for the requested bandwidth are enumerated below. (These values are guidelines.) Additional values will be defined as needed. Bandwidth encoding values are carried in a per protocol specific manner, see [RFC3473] and [RFC3472].
Bandwidth encodings are carried in 32 bit number in IEEE floating point format (the unit is bytes per second). For non-packet LSPs, it is useful to define discrete values to identify the bandwidth of the LSP. Some typical values for the requested bandwidth are enumerated below. (These values are guidelines.) Additional values will be defined as needed. Bandwidth encoding values are carried in a per protocol specific manner, see [RFC3473] and [RFC3472].
Signal Type (Bit-rate) Value (Bytes/Sec)
(IEEE Floating point)
-------------- --------------- ---------------------
DS0 (0.064 Mbps) 0x45FA0000
DS1 (1.544 Mbps) 0x483C7A00
E1 (2.048 Mbps) 0x487A0000
DS2 (6.312 Mbps) 0x4940A080
E2 (8.448 Mbps) 0x4980E800
Ethernet (10.00 Mbps) 0x49989680
E3 (34.368 Mbps) 0x4A831A80
DS3 (44.736 Mbps) 0x4AAAA780
STS-1 (51.84 Mbps) 0x4AC5C100
Fast Ethernet (100.00 Mbps) 0x4B3EBC20
E4 (139.264 Mbps) 0x4B84D000
FC-0 133M 0x4B7DAD68
OC-3/STM-1 (155.52 Mbps) 0x4B9450C0
FC-0 266M 0x4BFDAD68
FC-0 531M 0x4C7D3356
OC-12/STM-4 (622.08 Mbps) 0x4C9450C0
GigE (1000.00 Mbps) 0x4CEE6B28
FC-0 1062M 0x4CFD3356
OC-48/STM-16 (2488.32 Mbps) 0x4D9450C0
OC-192/STM-64 (9953.28 Mbps) 0x4E9450C0
10GigE-LAN (10000.00 Mbps) 0x4E9502F9
OC-768/STM-256 (39813.12 Mbps) 0x4F9450C0
Signal Type (Bit-rate) Value (Bytes/Sec) (IEEE Floating point) -------------- --------------- --------------------- DS0 (0.064 Mbps) 0x45FA0000 DS1 (1.544 Mbps) 0x483C7A00 E1 (2.048 Mbps) 0x487A0000 DS2 (6.312 Mbps) 0x4940A080 E2 (8.448 Mbps) 0x4980E800 Ethernet (10.00 Mbps) 0x49989680 E3 (34.368 Mbps) 0x4A831A80 DS3 (44.736 Mbps) 0x4AAAA780 STS-1 (51.84 Mbps) 0x4AC5C100 Fast Ethernet (100.00 Mbps) 0x4B3EBC20 E4 (139.264 Mbps) 0x4B84D000 FC-0 133M 0x4B7DAD68 OC-3/STM-1 (155.52 Mbps) 0x4B9450C0 FC-0 266M 0x4BFDAD68 FC-0 531M 0x4C7D3356 OC-12/STM-4 (622.08 Mbps) 0x4C9450C0 GigE (1000.00 Mbps) 0x4CEE6B28 FC-0 1062M 0x4CFD3356 OC-48/STM-16 (2488.32 Mbps) 0x4D9450C0 OC-192/STM-64 (9953.28 Mbps) 0x4E9450C0 10GigE-LAN (10000.00 Mbps) 0x4E9502F9 OC-768/STM-256 (39813.12 Mbps) 0x4F9450C0
Berger Standards Track [Page 10] RFC 3471 GMPLS Signaling Functional Description
Berger Standards Track [Page 10] RFC 3471 GMPLS Signaling Functional Description
3.2. Generalized Label
3.2. Generalized Label
The Generalized Label extends the traditional label by allowing the representation of not only labels which travel in-band with associated data packets, but also labels which identify time-slots, wavelengths, or space division multiplexed positions. For example, the Generalized Label may carry a label that represents (a) a single fiber in a bundle, (b) a single waveband within fiber, (c) a single wavelength within a waveband (or fiber), or (d) a set of time-slots within a wavelength (or fiber). It may also carry a label that represents a generic MPLS label, a Frame Relay label, or an ATM label (VCI/VPI).
The Generalized Label extends the traditional label by allowing the representation of not only labels which travel in-band with associated data packets, but also labels which identify time-slots, wavelengths, or space division multiplexed positions. For example, the Generalized Label may carry a label that represents (a) a single fiber in a bundle, (b) a single waveband within fiber, (c) a single wavelength within a waveband (or fiber), or (d) a set of time-slots within a wavelength (or fiber). It may also carry a label that represents a generic MPLS label, a Frame Relay label, or an ATM label (VCI/VPI).
A Generalized Label does not identify the "class" to which the label belongs. This is implicit in the multiplexing capabilities of the link on which the label is used.
Generalized Labelはラベルが属する「クラス」を特定しません。 これはラベルが使用されているリンクのマルチプレクシング能力で暗黙です。
A Generalized Label only carries a single level of label, i.e., it is non-hierarchical. When multiple levels of label (LSPs within LSPs) are required, each LSP must be established separately, see [MPLS- HIERARCHY].
Generalized Labelはただ一つのレベルのラベルを運ぶだけです、すなわち、それが非階層的です。 [MPLS- HIERARCHY]は、ラベル(LSPsの中のLSPs)の複数のレベルが必要であるときに、別々に各LSPを設立しなければならないのを見ます。
Each Generalized Label object/TLV carries a variable length label parameter.
それぞれのGeneralized Label物/TLVは可変長ラベルパラメタを運びます。
3.2.1. Required Information
3.2.1. 必須情報
The information carried in a Generalized Label is:
Generalized Labelで運ばれた情報は以下の通りです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: Variable Length
以下をラベルしてください。 可変長
Carries label information. The interpretation of this field
depends on the type of the link over which the label is used.
ラベル情報を運びます。 この分野の解釈はラベルが使用されているリンクのタイプに頼っています。
3.2.1.1. Port and Wavelength Labels
3.2.1.1. ポートと波長ラベル
Some configurations of fiber switching (FSC) and lambda switching (LSC) use multiple data channels/links controlled by a single control channel. In such cases the label indicates the data channel/link to be used for the LSP. Note that this case is not the same as when [MPLS-BUNDLE] is being used.
ファイバーの切り換え(FSC)とλの切り換え(LSC)のいくつかの構成が単一管理チャンネルによって制御された複数のデータ・チャンネル/リンクを使用します。 そのような場合ラベルは、LSPに使用されるためにデータ・チャンネル/リンクを示します。 本件が[MPLS-BUNDLE]が使用されている時と同じでないことに注意してください。
Berger Standards Track [Page 11] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[11ページ]RFC3471のGMPLSのシグナリングの機能的な記述
The information carried in a Port and Wavelength label is:
PortとWavelengthラベルで運ばれた情報は以下の通りです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label: 32 bits
以下をラベルしてください。 32ビット
Indicates port/fiber or lambda to be used, from the perspective of
the sender of the object/TLV. Values used in this field only have
significance between two neighbors, and the receiver may need to
convert the received value into a value that has local
significance. Values may be configured or dynamically determined
using a protocol such as [LMP].
物/TLVの送付者の見解から使用されるためにポート/ファイバーかλを示します。 この分野で使用される値は2人の隣人の間に意味を持っているだけです、そして、受信機はローカルの意味を持っている値に容認された値を変換する必要があるかもしれません。 値は、[LMP]などのプロトコルを使用することで構成されているか、またはダイナミックに決定しているかもしれません。
3.2.1.2. Other Labels
3.2.1.2. 他のラベル
Generic MPLS labels and Frame Relay labels are encoded right justified aligned in 32 bits (4 octets). ATM labels are encoded with the VPI right justified in bits 0-15 and the VCI right justified in bits 16-31.
一般的なMPLSラベルとFrame Relayラベルは32ビット(4つの八重奏)で並べられた状態で正当化されたコード化された権利です。 VPI権利がビット0-15で正当化されて、VCI権利がビット16-31で正当化されている状態で、ATMラベルはコード化されます。
3.3. Waveband Switching
3.3. 周波数帯の切り換え
A special case of lambda switching is waveband switching. A waveband represents a set of contiguous wavelengths which can be switched together to a new waveband. For optimization reasons it may be desirable for an optical cross connect to optically switch multiple wavelengths as a unit. This may reduce the distortion on the individual wavelengths and may allow tighter separation of the individual wavelengths. The Waveband Label is defined to support this special case.
λの切り換えの特別なケースは周波数帯の切り換えです。 周波数帯は新しい周波数帯に一緒に切り換えることができる1セットの隣接の波長を表します。 光学十字に、それが望ましいかもしれない最適化理由が光学的に複数の波長を一体にして切り換えるために接続するので。 これは、個々の波長におけるひずみを減少させて、個々の波長の、よりきつい分離を許容するかもしれません。 Waveband Labelは、この特別なケースを支えるために定義されます。
Waveband switching naturally introduces another level of label hierarchy and as such the waveband is treated the same way all other upper layer labels are treated.
ラベル階層構造、そのような周波数帯が他のすべての上側の層のラベルが扱われる同じように扱われるとき、周波数帯の切り換えは自然に別のレベルを導入します。
As far as the MPLS protocols are concerned there is little difference between a waveband label and a wavelength label except that semantically the waveband can be subdivided into wavelengths whereas the wavelength can only be subdivided into time or statistically multiplexed labels.
周波数帯ラベルと波長ラベルの間には、それを除いて、少しの違いが意味的にあるのがMPLSプロトコルに関する限り、周波数帯を波長に細分できますが、波長は時間まで細分しているか、または統計的に多重送信されたラベルであるにすぎないかもしれません。
Berger Standards Track [Page 12] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[12ページ]RFC3471のGMPLSのシグナリングの機能的な記述
3.3.1. Required information
3.3.1. 必須情報
Waveband switching uses the same format as the generalized label, see section 3.2.1.
セクション3.2.1は、周波数帯の切り換えが一般化されたラベルと同じ形式を使用するのを見ます。
In the context of waveband switching, the generalized label has the following format:
周波数帯の切り換えの文脈では、一般化されたラベルは以下の形式を持っています:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Waveband Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 周波数帯イド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | スタートラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 終わりのラベル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Waveband Id: 32 bits
周波数帯イド: 32ビット
A waveband identifier. The value is selected by the sender and
reused in all subsequent related messages.
周波数帯識別子。 値は、送付者によって選択されて、すべてのその後の関連するメッセージで再利用されます。
Start Label: 32 bits
ラベルを始動してください: 32ビット
Indicates the channel identifier of the lowest value wavelength
making up the waveband, from the object/TLV sender's
perspective.
物/TLV送付者の見解から周波数帯を作る最も低い値の波長に関するチャンネル識別子を示します。
End Label: 32 bits
ラベルを終わらせてください: 32ビット
Indicates the channel identifier of the highest value
wavelength making up the waveband, from the object/TLV sender's
perspective.
物/TLV送付者の見解から周波数帯を作る最も高い値の波長に関するチャンネル識別子を示します。
Channel identifiers are established either by configuration or by means of a protocol such as LMP [LMP]. They are normally used in the label parameter of the Generalized Label one PSC and LSC.
チャンネル識別子は構成かLMP[LMP]などのプロトコルによって確立されます。 通常、それらはGeneralized Label1PSCとLSCのラベルパラメタで使用されます。
3.4. Suggested Label
3.4. 提案されたラベル
The Suggested Label is used to provide a downstream node with the upstream node's label preference. This permits the upstream node to start configuring its hardware with the proposed label before the label is communicated by the downstream node. Such early configuration is valuable to systems that take non-trivial time to establish a label in hardware. Such early configuration can reduce
Suggested Labelは、上流のノードのラベル好みを川下のノードに提供するのに使用されます。 これは、ラベルが川下のノードによって伝えられる前に上流のノードが提案されたラベルでハードウェアを構成し始めることを許可します。 そのような早めの構成はラベルをハードウェアに証明するには重要な時間がかかるシステムに貴重です。 そのような早めの構成は減少できます。
Berger Standards Track [Page 13] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[13ページ]RFC3471のGMPLSのシグナリングの機能的な記述
setup latency, and may be important for restoration purposes where alternate LSPs may need to be rapidly established as a result of network failures.
潜在をセットアップしてください、そして、交互のLSPsがネットワーク失敗の結果、急速に設立される必要があるかもしれない回復目的のために重要であってもよいです。
The use of Suggested Label is only an optimization. If a downstream node passes a different label upstream, an upstream LSR reconfigures itself so that it uses the label specified by the downstream node, thereby maintaining the downstream control of a label. Note, the transmission of a suggested label does not imply that the suggested label is available for use. In particular, an ingress node should not transmit data traffic on a suggested label until the downstream node passes a label upstream.
Suggested Labelの使用は最適化にすぎません。 川下のノードが異なったラベル上流を通り過ぎるなら、上流のLSRがそれ自体を再構成するので、川下のノードによって指定されたラベルを使用します、その結果、ラベルの川下のコントロールを維持します。 注意、提案されたラベルのトランスミッションは、提案されたラベルが使用に利用可能であることを含意しません。 特に、川下のノードがラベル上流を通り過ぎるまで、イングレスノードは提案されたラベルにおけるデータ通信量を伝えるはずがありません。
The information carried in a suggested label is identical to a generalized label. Note, values used in the label field of a suggested label are from the object/TLV sender's perspective.
提案されたラベルで運ばれた情報は一般化されたラベルと同じです。 提案されたラベルのラベルフィールドで使用される値が物/TLV送付者の見解から来ていることに注意してください。
3.5. Label Set
3.5. ラベル・セット
The Label Set is used to limit the label choices of a downstream node to a set of acceptable labels. This limitation applies on a per hop basis.
Label Setは、川下のノードのラベル選択を1セットの許容できるラベルに制限するのに使用されます。 この制限はホップ基礎あたりのaで適用されます。
We describe four cases where a Label Set is useful in the optical domain. The first case is where the end equipment is only capable of transmitting on a small specific set of wavelengths/bands. The second case is where there is a sequence of interfaces which cannot support wavelength conversion (CI-incapable) and require the same wavelength be used end-to-end over a sequence of hops, or even an entire path. The third case is where it is desirable to limit the amount of wavelength conversion being performed to reduce the distortion on the optical signals. The last case is where two ends of a link support different sets of wavelengths.
私たちはLabel Setが光学ドメインで役に立つ4つのケースについて説明します。 最初のケースは終わりの設備が小さい特定のセットの波長/バンドを伝わることができるだけであるところです。 2番目のケースは中古の終わりから終わりが全体の経路であったとしても(CI不可能)で波長変換を支持して、同じ波長を必要とすることができないインタフェースの系列があるところです。 3番目のケースは光学信号におけるひずみを減少させるために実行される波長変換の量を制限するのが望ましいところです。 最後のケースはリンクの2つの端が異なった波長を支持するところです。
Label Set is used to restrict label ranges that may be used for a particular LSP between two peers. The receiver of a Label Set must restrict its choice of labels to one which is in the Label Set. Much like a label, a Label Set may be present across multiple hops. In this case each node generates its own outgoing Label Set, possibly based on the incoming Label Set and the node's hardware capabilities. This case is expected to be the norm for nodes with conversion incapable (CI-incapable) interfaces.
ラベルSetは、2人の同輩の間の特定のLSPに使用されるかもしれないラベル範囲を制限するのに使用されます。 Label Setの受信機はラベルの選択をLabel Setにあるものに制限しなければなりません。 ラベルのように、Label Setは複数のホップの向こう側に存在しているかもしれません。 この場合、各ノードはそれ自身の出発しているLabel Setを発生させます、ことによると入って来るLabel Setとノードのハードウェア能力に基づいて。 本件は変換の不可能な(CI不可能な)インタフェースがあるノードのための標準であると予想されます。
The use of Label Set is optional, if not present, all labels from the
valid label range may be used. Conceptually the absence of a Label
Set implies a Label Set whose value is {U}, the set of all valid
labels.
Label Setの使用が任意であるか、または存在している、有効なラベル範囲からのすべてのラベルが使用されるかもしれません。 概念的に、Label Setの不在は値がUであるLabel Setを含意します、すべての有効なラベルのセット。
Berger Standards Track [Page 14] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[14ページ]RFC3471のGMPLSのシグナリングの機能的な記述
3.5.1. Required Information
3.5.1. 必須情報
A label set is composed of one or more Label_Set objects/TLVs. Each object/TLV contains one or more elements of the Label Set. Each element is referred to as a subchannel identifier and has the same format as a generalized label.
ラベル・セットは1Label_Set物/TLVsで構成されます。 各物/TLVはLabel Setの1つ以上の要素を含んでいます。 各要素は、一般化されたラベルとしてサブチャネル識別子と呼ばれて、同じ書式を持っています。
The information carried in a Label_Set is:
Label_Setで運ばれた情報は以下の通りです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action | Reserved | Label Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel 1 |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: : :
: : :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subchannel N |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブチャネルN| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Action: 8 bits
動作: 8ビット
0 - Inclusive List
0--包括的なリスト
Indicates that the object/TLV contains one or more subchannel
elements that are included in the Label Set.
物/TLVがLabel Setに含まれている1つ以上のサブチャネル要素を含むのを示します。
1 - Exclusive List
1--排他的なリスト
Indicates that the object/TLV contains one or more subchannel
elements that are excluded from the Label Set.
物/TLVがLabel Setから除かれる1つ以上のサブチャネル要素を含むのを示します。
2 - Inclusive Range
2--包括的な範囲
Indicates that the object/TLV contains a range of labels. The
object/TLV contains two subchannel elements. The first element
indicates the start of the range. The second element indicates
the end of the range. A value of zero indicates that there is
no bound on the corresponding portion of the range.
物/TLVがさまざまなラベルを含むのを示します。 物/TLVは2つのサブチャネル要素を含んでいます。 最初の要素は範囲の始まりを示します。 2番目の要素は範囲の端を示します。 ゼロの値は、バウンドが全く範囲の対称部位にないのを示します。
Berger Standards Track [Page 15] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[15ページ]RFC3471のGMPLSのシグナリングの機能的な記述
3 - Exclusive Range
3--排他的な範囲
Indicates that the object/TLV contains a range of labels that
are excluded from the Label Set. The object/TLV contains two
subchannel elements. The first element indicates the start of
the range. The second element indicates the end of the range.
A value of zero indicates that there is no bound on the
corresponding portion of the range.
物/TLVがLabel Setから除かれるさまざまなラベルを含むのを示します。 物/TLVは2つのサブチャネル要素を含んでいます。 最初の要素は範囲の始まりを示します。 2番目の要素は範囲の端を示します。 ゼロの値は、バウンドが全く範囲の対称部位にないのを示します。
Reserved: 10 bits
予約される: 10ビット
This field is reserved. It MUST be set to zero on transmission and
MUST be ignored on receipt.
この分野は予約されています。 それをトランスミッションのときにゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
Label Type: 14 bits
タイプにレッテルを貼ってください: 14ビット
Indicates the type and format of the labels carried in the
object/TLV. Values are signaling protocol specific.
ラベルのタイプと形式が物/TLVで運ばれたのを示します。 値はシグナリングプロトコル特有です。
Subchannel:
サブチャネル:
The subchannel represents the label (wavelength, fiber ... ) which
is eligible for allocation. This field has the same format as
described for labels under section 3.2.
サブチャネルは配分に、適任のラベル(波長、ファイバー…)を表します。 この分野はセクション3.2の下でラベルのための説明されるのと同じ形式を持っています。
Note that subchannel to local channel identifiers (e.g.,
wavelength) mappings are a local matter.
市内回線識別子(例えば、波長)マッピングへのサブチャネルが地域にかかわる事柄であることに注意してください。
4. Bidirectional LSPs
4. 双方向のLSPs
This section defines direct support of bidirectional LSPs. Support is defined for LSPs that have the same traffic engineering requirements including fate sharing, protection and restoration, LSRs, and resource requirements (e.g., latency and jitter) in each direction. In the remainder of this section, the term "initiator" is used to refer to a node that starts the establishment of an LSP and the term "terminator" is used to refer to the node that is the target of the LSP. Note that for bidirectional LSPs, there is only one "initiator" and one "terminator".
このセクションは双方向のLSPsのダイレクトサポートを定義します。 サポートは同じである各指示に運命共有、保護、回復、LSRs、およびリソース要件(例えば、潜在とジター)を含む交通工学要件のを持っているLSPsのために定義されます。 このセクションの残りでは、「創始者」という用語はLSPの設立を始めるノードを参照するのに使用されます、そして、「ターミネータ」という用語は、LSPの目標であるノードを参照するのに使用されます。 双方向のLSPsのために、1「創始者」と1「ターミネータ」だけ、があることに注意してください。
Normally to establish a bidirectional LSP when using [RFC3209] or [RFC3212] two unidirectional paths must be independently established. This approach has the following disadvantages:
通常、[RFC3209]か[RFC3212]を使用するとき、双方向のLSPを証明するために、独自に2つの単方向の経路を確立しなければなりません。 このアプローチには、以下の損失があります:
* The latency to establish the bidirectional LSP is equal to one
round trip signaling time plus one initiator-terminator signaling
transit delay. This not only extends the setup latency for
successful LSP establishment, but it extends the worst-case
* 双方向のLSPを設立する潜在は、トランジット遅れに合図しながら、ある周遊旅行シグナリング時間と1つの創始者ターミネータと等しいです。 これはうまくいっているLSP設立のためにセットアップ潜在を広げるだけではありませんが、それは最悪の場合を広げています。
Berger Standards Track [Page 16] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[16ページ]RFC3471のGMPLSのシグナリングの機能的な記述
latency for discovering an unsuccessful LSP to as much as two
times the initiator-terminator transit delay. These delays are
particularly significant for LSPs that are established for
restoration purposes.
創始者ターミネータトランジット遅れの最大2倍に失敗のLSPを発見するための潜在。 回復目的のために設立されるLSPsには、これらの遅れは特に重要です。
* The control overhead is twice that of a unidirectional LSP. This
is because separate control messages (e.g., Path and Resv) must be
generated for both segments of the bidirectional LSP.
* コントロールオーバーヘッドは単方向のものの2倍LSPです。 これは別々のコントロールメッセージ(例えば、PathとResv)が双方向のLSPの両方のセグメントのために発生しなければならないからです。
* Because the resources are established in separate segments, route
selection is complicated. There is also additional potential race
for conditions in assignment of resources, which decreases the
overall probability of successfully establishing the bidirectional
connection.
* リソースが別々のセグメントに確立されるので、ルート選択は複雑です。 また、リソースの課題には状態のための追加潜在的人種がいます。(それは、首尾よく双方向の接続を確立するという総合的な確率を減少させます)。
* It is more difficult to provide a clean interface for SONET/SDH
equipment that may rely on bidirectional hop-by-hop paths for
protection switching.
* 保護の切り換えのためにホップごとの双方向の経路を当てにするかもしれないSonet/SDH設備に清潔なインタフェースを供給するのは、より難しいです。
* Bidirectional optical LSPs (or lightpaths) are seen as a
requirement for many optical networking service providers.
* 双方向の光学LSPs(または、lightpaths)は多くの光学ネットワークサービスプロバイダーのための要件と考えられます。
With bidirectional LSPs both the downstream and upstream data paths, i.e., from initiator to terminator and terminator to initiator, they are established using a single set of signaling messages. This reduces the setup latency to essentially one initiator-terminator round trip time plus processing time, and limits the control overhead to the same number of messages as a unidirectional LSP.
双方向のLSPsに伴う両方の川下の、そして、上流のデータ経路、すなわち、創始者からターミネータとターミネータから創始者まで、それらは、1セットのシグナリングメッセージを使用することで設立されます。 これは、単方向LSPとして本質的にはある創始者ターミネータ周遊旅行時間と処理時間にセットアップレイテンシを減少させて、コントロールオーバーヘッドを同じ数のメッセージに制限します。
4.1. Required Information
4.1. 必須情報
For bidirectional LSPs, two labels must be allocated. Bidirectional LSP setup is indicated by the presence of an Upstream Label object/TLV in the appropriate signaling message. An Upstream Label has the same format as the generalized label, see Section 3.2.
双方向のLSPsに関しては、2個のラベルを割り当てなければなりません。 双方向のLSPセットアップは適切なシグナリングメッセージでのUpstream Label物/TLVの存在によって示されます。 セクション3.2は、Upstream Labelには一般化されたラベルと同じ形式があるのを見ます。
4.2. Contention Resolution
4.2. 主張解決
Contention for labels may occur between two bidirectional LSP setup requests traveling in opposite directions. This contention occurs when both sides allocate the same resources (labels) at effectively the same time. If there is no restriction on the labels that can be used for bidirectional LSPs and if there are alternate resources, then both nodes will pass different labels upstream and there is no contention. However, if there is a restriction on the labels that can be used for the bidirectional LSPs (for example, if they must be physically coupled on a single I/O card), or if there are no more resources available, then the contention must be resolved by other
ラベルのための主張は、それぞれ反対の方向に旅行しながら、2つの双方向のLSPセットアップ要求の間に起こるかもしれません。 両側が事実上同時に同じリソース(ラベル)を割り当てるとき、この主張は起こります。 双方向のLSPsに使用できるラベルの上に制限が全くなくて、交互のリソースがあると、両方のノードは上流へ異なったラベルを渡すでしょう、そして、主張が全くありません。 しかしながら、双方向のLSPsに使用できるラベルの上に制限があるか(例えば物理的に単一の入出力カードと彼らを結合しなければならないなら)、または利用可能なそれ以上のリソースがなければ、他で主張を決議しなければなりません。
Berger Standards Track [Page 17] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[17ページ]RFC3471のGMPLSのシグナリングの機能的な記述
means. To resolve contention, the node with the higher node ID will win the contention and it MUST issue a PathErr/NOTIFICATION message with a "Routing problem/Label allocation failure" indication. Upon receipt of such an error, the node SHOULD try to allocate a different Upstream label (and a different Suggested Label if used) to the bidirectional path. However, if no other resources are available, the node must proceed with standard error handling.
意味します。 主張を決議するために、より高いノードIDがあるノードは主張を得るでしょう、そして、それは「ルート設定問題/ラベル割り振りの失敗」指示でPathErr/NOTIFICATIONメッセージを発行しなければなりません。 そのような誤りを受け取り次第ノードSHOULDが異なったUpstreamラベルを割り当てようとする、(異なったSuggested Label、使用される、)、双方向の経路に。 しかしながら、他のどんなリソースも利用可能でないなら、ノードは標準誤差取り扱いを続けなければなりません。
To reduce the probability of contention, one may impose a policy that the node with the lower ID never suggests a label in the downstream direction and always accepts a Suggested Label from an upstream node with a higher ID. Furthermore, since the labels may be exchanged using LMP, an alternative local policy could further be imposed such that (with respect to the higher numbered node's label set) the higher numbered node could allocate labels from the high end of the label range while the lower numbered node allocates labels from the low end of the label range. This mechanism would augment any close packing algorithms that may be used for bandwidth (or wavelength) optimization. One special case that should be noted when using RSVP and supporting this approach is that the neighbor's node ID might not be known when sending an initial Path message. When this case occurs, a node should suggest a label chosen at random from the available label space.
主張では、下側のIDがあるノードが決して示さない方針を課すかもしれないという確率を減少させるために、ラベルは、より高いIDと共に上流のノードからSuggested Labelを川下の指示といつも受け入れます。 その上、LMPを使用することでラベルを交換するかもしれないので、低い番号付のノードがラベル範囲のローエンドからラベルを割り当てている間、(より高い番号付のノードのラベル・セットに関する)より高い番号付のノードがラベル範囲の上位からラベルを割り当てることができるように、さらに代替のローカルの方針を課すことができました。 このメカニズムは帯域幅(または、波長)最適化に使用されるかもしれないアルゴリズムを梱包するどんな閉鎖も増大させるでしょう。 RSVPを使用して、このアプローチを支持するとき注意されるべきである1つの特別なケースは初期のPathメッセージを送るとき、隣人のノードIDが知られていないかもしれないということです。 本件が現れると、ノードは利用可能なラベルスペースから無作為に選ばれたラベルを示すはずです。
An example of contention between two nodes (PXC 1 and PXC 2) is shown in Figure 1. In this example PXC 1 assigns an Upstream Label for the channel corresponding to local BCId=2 (local BCId=7 on PXC 2) and sends a Suggested Label for the channel corresponding to local BCId=1 (local BCId=6 on PXC 2). Simultaneously, PXC 2 assigns an Upstream Label for the channel corresponding to its local BCId=6 (local BCId=1 on PXC 1) and sends a Suggested Label for the channel corresponding to its local BCId=7 (local BCId=2 on PXC 1). If there is no restriction on the labels that can be used for bidirectional LSPs and if there are alternate resources available, then both PXC 1 and PXC 2 will pass different labels upstream and the contention is resolved naturally (see Fig. 2). However, if there is a restriction on the labels that can be used for bidirectional LSPs (for example, if they must be physically coupled on a single I/O card), then the contention must be resolved using the node ID (see Fig. 3).
2つのノード(PXC1とPXC2)の間の主張に関する例は図1に示されます。 この例では、PXC1は地方のBCId=2(PXC2の上の地方のBCId=7)に対応するチャンネルのためにUpstream Labelを割り当てて、地方のBCId=1(PXC2の上の地方のBCId=6)に対応するチャンネルのためにSuggested Labelを送ります。 同時に、PXC2は地方のBCId=6(PXC1の上の地方のBCId=1)に対応するチャンネルのためにUpstream Labelを割り当てて、地方のBCId=7(PXC1の上の地方のBCId=2)に対応するチャンネルのためにSuggested Labelを送ります。 双方向のLSPsに使用できるラベルの上に制限が全くなくて、利用可能な交互のリソースがあると、PXC1とPXC2の両方が上流へ異なったラベルを渡すでしょう、そして、主張は自然に決議されています(図2を参照してください)。 しかしながら、双方向のLSPsに使用できるラベルの上に制限があれば(例えば物理的に単一の入出力カードと彼らを結合しなければならないなら)、ノードIDを使用することで主張を決議しなければなりません(図3を参照してください)。
Berger Standards Track [Page 18] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[18ページ]RFC3471のGMPLSのシグナリングの機能的な記述
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + SL1,UL2 + +
+ 1 +------------------------>+ 6 +
+ + UL1, SL2 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + + +
+ 3 +------------------------>+ 8 +
+ + + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
Figure 1. Label Contention
+------------+ +------------+ + PXC1++PXC2+++SL1、UL2+++1+------------------------>+6+++UL1、SL2+++2+<。------------------------+ 7 + + + + + + + + + + 3 +------------------------+ + + + + >+8+4+<。------------------------+ 9 + +------------+ +------------+ 図1。 ラベル主張
In this example, PXC 1 assigns an Upstream Label using BCId=2 (BCId=7 on PXC 2) and a Suggested Label using BCId=1 (BCId=6 on PXC 2). Simultaneously, PXC 2 assigns an Upstream Label using BCId=6 (BCId=1 on PXC 1) and a Suggested Label using BCId=7 (BCId=2 on PXC 1).
この例では、PXC1は、BCId=1(PXC2の上のBCId=6)を使用することでBCId=2(PXC2の上のBCId=7)とSuggested Labelを使用することでUpstream Labelを割り当てます。 同時に、PXC2は、BCId=7(PXC1の上のBCId=2)を使用することでBCId=6(PXC1の上のBCId=1)とSuggested Labelを使用することでUpstream Labelを割り当てます。
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + UL2 + +
+ 1 +------------------------>+ 6 +
+ + UL1 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + L1 + +
+ 3 +------------------------>+ 8 +
+ + L2 + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
+------------+ +------------+ + PXC1++PXC2+++UL2+++1+------------------------+ + >+6+UL1+++2+<。------------------------+ 7 + + + + + + + L1+++3+------------------------+ + >+8+L2+++4+<。------------------------+ 9 + +------------+ +------------+
Figure 2. Label Contention Resolution without resource restrictions
図2。 リソース制限のないラベルContention Resolution
Berger Standards Track [Page 19] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[19ページ]RFC3471のGMPLSのシグナリングの機能的な記述
In this example, there is no restriction on the labels that can be used by the bidirectional connection and there is no contention.
この例には、双方向の接続が使用できるラベルの上に制限が全くありません、そして、主張が全くありません。
+------------+ +------------+
+ PXC 1 + + PXC 2 +
+ + UL2 + +
+ 1 +------------------------>+ 6 +
+ + L2 + +
+ 2 +<------------------------+ 7 +
+ + + +
+ + L1 + +
+ 3 +------------------------>+ 8 +
+ + UL1 + +
+ 4 +<------------------------+ 9 +
+------------+ +------------+
+------------+ +------------+ + PXC1++PXC2+++UL2+++1+------------------------+ + >+6+L2+++2+<。------------------------+ 7 + + + + + + + L1+++3+------------------------+ + >+8+UL1+++4+<。------------------------+ 9 + +------------+ +------------+
Figure 3. Label Contention Resolution with resource restrictions
図3。 リソース制限があるラベルContention Resolution
In this example, labels 1,2 and 3,4 on PXC 1 (labels 6,7 and 8,9 on PXC 2, respectively) must be used by the same bidirectional connection. Since PXC 2 has a higher node ID, it wins the contention and PXC 1 must use a different set of labels.
この例では、同じ双方向の接続はPXC1(それぞれPXC2の上のラベル6、7、および8、9)の上のラベル1、2、および3、4を使用しなければなりません。 PXC2には、より高いノードIDがあるので、主張を得ます、そして、PXC1は異なったセットのラベルを使用しなければなりません。
5. Notification on Label Error
5. ラベル誤りに関する通知
There are cases in traditional MPLS and in GMPLS that result in an error message containing an "Unacceptable label value" indication, see [RFC3209], [RFC3472] and [RFC3473]. When these cases occur, it can be useful for the node generating the error message to indicate which labels would be acceptable. To cover this case, GMPLS introduces the ability to convey such information via the "Acceptable Label Set". An Acceptable Label Set is carried in appropriate protocol specific error messages, see [RFC3472] and [RFC3473].
そこでは、[RFC3209]、[RFC3472]、および[RFC3473]が、伝統的なMPLSとGMPLSのケースが「容認できないラベル値」指示を含むエラーメッセージのその結果であると考えます。 これらのケースが現れるとき、どのラベルが許容できるかを示すのはエラーメッセージを発生させるノードの役に立つ場合があります。 本件をカバーするために、GMPLSは「許容できるラベル・セット」を通してそのような情報を伝える能力を導入します。 [RFC3472]と[RFC3473]は、Acceptable Label Setが適切なプロトコル特定のエラーメッセージで運ばれるのを見ます。
The format of an Acceptable Label Set is identical to a Label Set, see section 3.5.1.
セクション3.5.1は、Acceptable Label Setの形式がLabel Setと同じであることを見ます。
6. Explicit Label Control
6. 明白なラベルコントロール
In traditional MPLS, the interfaces used by an LSP may be controlled via an explicit route, i.e., ERO or ER-Hop. This enables the inclusion of a particular node/interface, and the termination of an LSP on a particular outgoing interface of the egress LSR. Where the interface may be numbered or unnumbered, see [MPLS-UNNUM].
伝統的なMPLSでは、LSPによって使用されたインタフェースは、すなわち、明白なルート、EROを通して制御されるか、またはER跳ぶかもしれません。 これは特定のノード/インタフェースの包含、および出口LSRの特定の外向的なインタフェースにおけるLSPの終了を可能にします。 インタフェースが番号付である、または無数であるかもしれないところでは、[MPLS-UNNUM]を見てください。
There are cases where the existing explicit route semantics do not provide enough information to control the LSP to the degree desired. This occurs in the case when the LSP initiator wishes to select a
既存の明白なルート意味論が制御できるくらいの情報を提供しない程度へのLSPが望んでいたケースがあります。 LSP創始者がaを選択したがっているとき、これは場合で起こります。
Berger Standards Track [Page 20] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[20ページ]RFC3471のGMPLSのシグナリングの機能的な記述
label used on a link. Specifically, the problem is that ERO and ER- Hop do not support explicit label sub-objects. An example case where such a mechanism is desirable is where there are two LSPs to be "spliced" together, i.e., where the tail of the first LSP would be "spliced" into the head of the second LSP. This last case is more likely to be used in the non-PSC classes of links.
リンクの上に使用されるラベル。 明確に、問題はEROとERホップが明白なラベルサブ物を支えないということです。 そのようなメカニズムが望ましい例のケースはすなわち、最初のLSPのテールが第2LSPのヘッドに「継がれる」ところに一緒に「継がれる」ために2LSPsがあるところです。 リンクの非PSCのクラスではこの最後のケースは、より使用されそうです。
To cover this case, the Label ERO subobject / ER Hop is introduced.
本件をカバーするために、Label ERO subobject / ER Hopを導入します。
6.1. Required Information
6.1. 必須情報
The Label Explicit and Record Routes contains:
Label ExplicitとRecord Routesは以下を含んでいます。
L: 1 bit
L: 1ビット
This bit must be set to 0.
このビットを0に設定しなければなりません。
U: 1 bit
U: 1ビット
This bit indicates the direction of the label. It is 0 for the
downstream label. It is set to 1 for the upstream label and is
only used on bidirectional LSPs.
このビットはラベルの指示を示します。 それは川下のラベルのための0です。 それは、上流のラベルのために1に設定されて、双方向のLSPsで使用されるだけです。
Label: Variable
以下をラベルしてください。 変数
This field identifies the label to be used. The format of this
field is identical to the one used by the Label field in
Generalized Label, see Section 3.2.1.
この分野は、使用されるためにラベルを特定します。 この分野の形式はGeneralized LabelのLabel分野によって使用されるものと同じです、とセクション3.2.1が見ます。
Placement and ordering of these parameters are signaling protocol specific.
これらのパラメタのプレースメントと注文はシグナリングプロトコル特有です。
7. Protection Information
7. 保護情報
Protection Information is carried in a new object/TLV. It is used to indicate link related protection attributes of a requested LSP. The use of Protection Information for a particular LSP is optional. Protection Information currently indicates the link protection type desired for the LSP. If a particular protection type, i.e., 1+1, or 1:N, is requested, then a connection request is processed only if the desired protection type can be honored. Note that the protection capabilities of a link may be advertised in routing, see [GMPLS-RTG]. Path computation algorithms may take this information into account when computing paths for setting up LSPs.
保護情報は新しい物/TLVで運ばれます。 それは、リンクが要求されたLSPの保護属性を関係づけたのを示すのに使用されます。 Protection情報の特定のLSPの使用は任意です。 保護情報は現在、LSPのために望まれていたリンク保護タイプを示します。 1:Nは要求されて、当時のa接続要求です。特定の保護であるならすなわち、タイプしてください、1、+1、必要な保護タイプが光栄に思う場合がある場合にだけ、処理されます。 リンクの保護能力がルーティングで広告を出すかもしれないことに注意してください、そして、[GMPLS-RTG]を見てください。 LSPsをセットアップするために経路を計算するとき、経路計算アルゴリズムはこの情報を考慮に入れるかもしれません。
Protection Information also indicates if the LSP is a primary or secondary LSP. A secondary LSP is a backup to a primary LSP. The resources of a secondary LSP are not used until the primary LSP
また、保護情報は、LSPが第一の、または、二次のLSPであるかどうかを示します。 二次LSPは第一のLSPへのバックアップです。 二次LSPに関するリソースは第一のLSPまで使用されません。
Berger Standards Track [Page 21] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[21ページ]RFC3471のGMPLSのシグナリングの機能的な記述
fails. The resources allocated for a secondary LSP MAY be used by other LSPs until the primary LSP fails over to the secondary LSP. At that point, any LSP that is using the resources for the secondary LSP MUST be preempted.
失敗します。 リソースは2番目のためにLSP MAYを割り当てました。第一のLSPが二次のLSPに失敗するまで、他のLSPsによって使用されてください。 そのポイント、二次LSP MUSTにリソースを使用しているあらゆるLSPで、先取りされてください。
7.1. Required Information
7.1. 必須情報
The following information is carried in Protection Information:
以下の情報はProtection情報で運ばれます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved | Link Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| 予約されます。| リンク旗| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Secondary (S): 1 bit
二次(S): 1ビット
When set, indicates that the requested LSP is a secondary LSP.
いつが、セットして、要求されたLSPが二次LSPであることを示しますか?
Reserved: 25 bits
予約される: 25ビット
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt. These bits SHOULD be pass
through unmodified by transit nodes.
この分野は予約されています。 それをトランスミッションのときにゼロに設定しなければならなくて、領収書の上で無視しなければなりません。 これらのビットSHOULD、トランジットノードで変更されていなく通り抜けることになってください。
Link Flags: 6 bits
旗をリンクしてください: 6ビット
Indicates desired link protection type. As previously
mentioned, protection capabilities of a link may be advertised
in routing. A value of 0 implies that any, including no, link
protection may be used. More than one bit may be set to
indicate when multiple protection types are acceptable. When
multiple bits are set and multiple protection types are
available, the choice of protection type is a local (policy)
decision.
必要なリンク保護タイプを示します。 以前に言及されるように、ルーティングでリンクの保護能力の広告を出すかもしれません。 0の値は、いいえを含んでいて、いくらか、リンク保護が使用されるかもしれないのを含意します。 1ビット以上が、多重防護タイプがいつ許容しているかを示すように設定されるかもしれません。 複数のビットが設定されて、多重防護タイプが手があいているとき、保護タイプの選択はローカルの(方針)決定です。
The following flags are defined:
以下の旗は定義されます:
0x20 Enhanced
高められた0×20
Indicates that a protection scheme that is more reliable than
Dedicated 1+1 should be used, e.g., 4 fiber BLSR/MS-SPRING.
例えば使用されるべきです。そのDedicatedより信頼できるa保護計画について簡単に述べる、1、+1、4ファイバーSPRING BLSR/さん。
Berger Standards Track [Page 22] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[22ページ]RFC3471のGMPLSのシグナリングの機能的な記述
0x10 Dedicated 1+1
0×10は+1に1を捧げました。
Indicates that a dedicated link layer protection scheme,
i.e., 1+1 protection, should be used to support the LSP.
ひたむきなリンクレイヤ保護計画(すなわち、1+1保護)がLSPを支持するのに使用されるべきであるのを示します。
0x08 Dedicated 1:1
0×08 ひたむきな1:1
Indicates that a dedicated link layer protection scheme,
i.e., 1:1 protection, should be used to support the LSP.
ひたむきなリンクレイヤ保護計画(すなわち、1:1保護)がLSPを支持するのに使用されるべきであるのを示します。
0x04 Shared
0×04は共有されました。
Indicates that a shared link layer protection scheme, such
as 1:N protection, should be used to support the LSP.
1:N保護などの共有されたリンクレイヤ保護計画がLSPを支持するのに使用されるべきであるのを示します。
0x02 Unprotected
0×02、保護のなさ
Indicates that the LSP should not use any link layer
protection.
LSPが少しのリンクレイヤ保護も使用するはずがないのを示します。
0x01 Extra Traffic
0×01 余分な交通
Indicates that the LSP should use links that are protecting
other (primary) traffic. Such LSPs may be preempted when
the links carrying the (primary) traffic being protected
fail.
LSPが他の(第一)の交通を保護しているリンクを使用するはずであるのを示します。 保護される(第一)の交通を運ぶリンクが失敗すると、そのようなLSPsは先取りされるかもしれません。
8. Administrative Status Information
8. 管理状態情報
Administrative Status Information is carried in a new object/TLV. Administrative Status Information is currently used in two ways. In the first, the information indicates administrative state with respect to a particular LSP. In this usage, Administrative Status Information indicates the state of the LSP. State indications include "up" or "down", if it is in a "testing" mode, and if deletion is in progress. The actions taken by a node based on a state local decision. An example action that may be taken is to inhibit alarm reporting when an LSP is in "down" or "testing" states, or to report alarms associated with the connection at a priority equal to or less than "Non service affecting".
管理Status情報は新しい物/TLVで運ばれます。 管理Status情報は現在、2つの方法で使用されます。 1番目では、情報は特定のLSPに関して管理状態を示します。 この用法で、Administrative Status情報はLSPの州を示します。 それがあるなら、「テスト」モードと進行中で削除があるかに州の指摘は“up"か“down"を含んでいます。 ノードによって取られた行動はローカルの決定を状態に基礎づけました。 取られるかもしれない例の行動は、アラームがLSPが“down"にあるとき、報告するか、または州を「テストすること」を禁止するか、または優先における接続に関連しているアラームが「非サービス影響」より等しいか、または少ないと報告することです。
In the second usage of Administrative Status Information, the information indicates a request to set an LSP's administrative state. This information is always relayed to the ingress node which acts on the request.
Administrative Status情報の2番目の用法で、情報はLSPの管理状態を設定するという要求を示します。 どれが要求に影響するかというこの情報はいつもイングレスノードにリレーされます。
Berger Standards Track [Page 23] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[23ページ]RFC3471のGMPLSのシグナリングの機能的な記述
The different usages are distinguished in a protocol specific fashion. See [RFC3473] and [RFC3472] for details. The use of Administrative Status Information for a particular LSP is optional.
異なった用法はプロトコルの特定のファッションで区別されます。 詳細に関して[RFC3473]と[RFC3472]を見てください。 Administrative Status情報の特定のLSPの使用は任意です。
8.1. Required Information
8.1. 必須情報
The following information is carried in Administrative Status Information:
以下の情報はAdministrative Status情報で運ばれます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| 予約されます。|T|A|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reflect (R): 1 bit
(R)を反映してください: 1ビット
When set, indicates that the edge node SHOULD reflect the
object/TLV back in the appropriate message. This bit MUST NOT
be set in state change request, i.e., Notify, messages.
いつが、セットして、縁のノードSHOULDが適切なメッセージの物/TLV後部を反映するのを示しますか? すなわち、州の変更要求、Notify、メッセージにこのビットを設定してはいけません。
Reserved: 28 bits
予約される: 28ビット
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt. These bits SHOULD be pass
through unmodified by transit nodes.
この分野は予約されています。 それをトランスミッションのときにゼロに設定しなければならなくて、領収書の上で無視しなければなりません。 これらのビットSHOULD、トランジットノードで変更されていなく通り抜けることになってください。
Testing (T): 1 bit
(T)をテストします: 1ビット
When set, indicates that the local actions related to the
"testing" mode should be taken.
いつが、セットして、「テスト」モードに関連する地方の行動が取られるべきであるのを示しますか?
Administratively down (A): 1 bit
(A)より行政上倒してください: 1ビット
When set, indicates that the local actions related to the
"administratively down" state should be taken.
いつが、セットして、「行政上ダウンしてください」という状態に関連する地方の行動が取られるべきであるのを示しますか?
Deletion in progress (D): 1 bit
進行中(D)における削除: 1ビット
When set, indicates that that the local actions related to LSP
teardown should be taken. Edge nodes may use this flag to
control connection teardown.
いつが、セットして、地方の動きがLSP分解に関係づけたそれが取られるべきであるのを示しますか? 縁のノードは、接続分解を制御するのにこの旗を使用するかもしれません。
Berger Standards Track [Page 24] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[24ページ]RFC3471のGMPLSのシグナリングの機能的な記述
9. Control Channel Separation
9. コントロールチャネルセパレーション
The concept of a control channel being different than a data channel being signaled was introduced to MPLS in connection with link bundling, see [MPLS-BUNDLE]. In GMPLS, the separation of control and data channel may be due to any number of factors. (Including bundling and other cases such as data channels that cannot carry in- band control information.) This section will cover the two critical related issues: the identification of data channels in signaling and handling of control channel failures that don't impact data channels.
制御チャンネルの概念がリンクバンドリングに関して合図されるデータ・チャンネルをMPLSに導入したより異なっていて、[MPLS-BUNDLE]を見てください。 GMPLSに、コントロールとデータ・チャンネルの離別がどんな多くの要因のためにもあるかもしれません。 (コネバンド制御情報を運ぶことができないデータ・チャンネルなどのバンドリングと他のケースを含んでいます。) このセクションは批判的な関連する2冊をカバーするでしょう: データの識別はデータ・チャンネルに影響を与えないコントロールチャンネルの故障のシグナリングと取り扱いで向けられます。
9.1. Interface Identification
9.1. インタフェース識別
In traditional MPLS there is an implicit one-to-one association of a control channel to a data channel. When such an association is present, no additional or special information is required to associate a particular LSP setup transaction with a particular data channel. (It is implicit in the control channel over which the signaling messages are sent.)
伝統的なMPLSに、データ・チャンネルの制御チャンネルの内在している1〜1つの協会があります。 そのような協会が存在しているとき、どんな追加しているか特別な情報も、特定のLSPセットアップ取引を特定のデータ・チャンネルに関連づけるのに必要ではありません。 (それはシグナリングメッセージが送られる制御チャンネルで暗黙です。)
In cases where there is not an explicit one-to-one association of control channels to data channels it is necessary to convey additional information in signaling to identify the particular data channel being controlled. GMPLS supports explicit data channel identification by providing interface identification information. GMPLS allows the use of a number of interface identification schemes including IPv4 or IPv6 addresses, interface indexes (see [MPLS- UNNUM]) and component interfaces (established via configuration or a protocol such as [LMP]). In all cases the choice of the data interface is indicated by the upstream node using addresses and identifiers used by the upstream node.
データ・チャンネルの制御チャンネルの明白な1〜1つの協会がない場合では、制御されていて、特定のデータ・チャンネルを特定すると合図する際に追加情報を伝えるのが必要です。 GMPLSは、インタフェース識別情報を提供することによって、明白なデータチャネル識別を支持します。 GMPLSはIPv4かIPv6アドレスと、インタフェースインデックス([MPLS- UNNUM]を見る)とコンポーネントインタフェース(構成か[LMP]などのプロトコルで、設立される)を含む多くのインタフェース識別計画の使用を許します。 すべての場合では、データインタフェースの選択は、上流のノードによって上流のノードによって使用されるアドレスと識別子を使用することで示されます。
9.1.1. Required Information
9.1.1. 必須情報
The following information is carried in Interface_ID:
以下の情報はInterface_IDで運ばれます:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Berger Standards Track [Page 25] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[25ページ]RFC3471のGMPLSのシグナリングの機能的な記述
Where each TLV has the following format:
各TLVには以下があるところでは、以下をフォーマットしてください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ 値~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length: 16 bits
長さ: 16ビット
Indicates the total length of the TLV, i.e., 4 + the length of
the value field in octets. A value field whose length is not a
multiple of four MUST be zero-padded so that the TLV is four-
octet aligned.
すなわち、TLV、+ 八重奏における、値の分野の長さの4の全長を示します。 長さが4の倍数でない値の分野が無そっと歩くに違いないので、TLVは並べられた4八重奏です。
Type: 16 bits
以下をタイプしてください。 16ビット
Indicates type of interface being identified. Defined values
are:
特定されるインタフェースのタイプを示します。 定義された値は以下の通りです。
Type Length Format Description
--------------------------------------------------------------------
1 8 IPv4 Addr. IPv4
2 20 IPv6 Addr. IPv6
3 12 See below IF_INDEX (Interface Index)
4 12 See below COMPONENT_IF_DOWNSTREAM (Component interface)
5 12 See below COMPONENT_IF_UPSTREAM (Component interface)
長さの書式の記述をタイプしてください。-------------------------------------------------------------------- 1 8IPv4 Addr。 IPv4 2 20IPv6 Addr。 以下のIPv6 3 12See、_COMPONENTの下のINDEX(インタフェースIndex)4 12Seeである、__COMPONENT_の下のDOWNSTREAM(コンポーネントインタフェース)5 12Seeである、_UPSTREAMです。(コンポーネントインタフェース)
For types 3, 4 and 5 the Value field has the format:
タイプ3、4、および5のために、Value分野には、形式があります:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | インタフェースID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Address: 32 bits
IPアドレス: 32ビット
The IP address field may carry either an IP address of a link
or an IP address associated with the router, where associated
address is the value carried in a router address TLV of
routing.
IPアドレス・フィールドはリンクのIPアドレスかルータに関連しているIPアドレスのどちらかを運ぶかもしれません。そこでは、関連アドレスがルーティングのルータアドレスTLVで運ばれた値です。
Berger Standards Track [Page 26] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[26ページ]RFC3471のGMPLSのシグナリングの機能的な記述
Interface ID: 32 bits
IDを連結してください: 32ビット
For type 3 usage, the Interface ID carries an interface
identifier.
タイプ3用法のために、Interface IDはインタフェース識別子を運びます。
For types 4 and 5, the Interface ID indicates a bundled
component link. The special value 0xFFFFFFFF can be used to
indicate the same label is to be valid across all component
links.
タイプ4と5のために、Interface IDは束ねられたコンポーネントリンクを示します。 同じラベルがすべてのコンポーネントリンクの向こう側に有効であることになっていることを示すのに特別な値の0xFFFFFFFFを使用できます。
9.2. Fault Handling
9.2. 欠点取り扱い
There are two new faults that must be handled when the control channel is independent of the data channel. In the first, there is a link or other type of failure that limits the ability of neighboring nodes to pass control messages. In this situation, neighboring nodes are unable to exchange control messages for a period of time. Once communication is restored the underlying signaling protocol must indicate that the nodes have maintained their state through the failure. The signaling protocol must also ensure that any state changes that were instantiated during the failure are synchronized between the nodes.
制御チャンネルがデータ・チャンネルから独立しているとき扱わなければならない2つの新しい欠点があります。 1番目に、隣接しているノードの能力をパス制御メッセージに制限するリンクか他のタイプの失敗があります。 この状況で、隣接しているノードはしばらく、コントロールメッセージを交換できません。 コミュニケーションがいったん回復すると、基本的なシグナリングプロトコルは、ノードが失敗を通してそれらの状態を維持したのを示さなければなりません。 また、シグナリングプロトコルは、失敗の間に例示されたどんな州の変化もノードの間で連動するのを確実にしなければなりません。
In the second, a node's control plane fails and then restarts and losses most of its state information. In this case, both upstream and downstream nodes must synchronize their state information with the restarted node. In order for any resynchronization to occur the node undergoing the restart will need to preserve some information, such as its mappings of incoming to outgoing labels.
2番目では、ノードの制御飛行機は、失敗して、次に、再開して、損失は州の情報の大部分を再開します。 この場合、上流の、そして、川下の両方のノードはそれらの州の情報を再開しているノードと同期させなければなりません。 どんな再同期も現れるように、再開を受けるノードは、何らかの情報を保存する必要があるでしょう、出発しているラベルへの入来に関するマッピングなどのように。
Both cases are addressed in protocol specific fashions, see [RFC3473] and [RFC3472].
[RFC3473]と[RFC3472]は、両方のケースが記述されて、特定のファッションが中で議定書を作るということであることを見ます。
Note that these cases only apply when there are mechanisms to detect data channel failures independent of control channel failures.
コントロールチャンネルの故障の如何にかかわらずデータ・チャンネルの故障を検出するためにメカニズムがあるときだけ、これらのケースが適用されることに注意してください。
10. Acknowledgments
10. 承認
This document is the work of numerous authors and consists of a composition of a number of previous documents in this area.
このドキュメントは、多数の作者の仕事であり、この領域での前の多くのドキュメントの構成から成ります。
Valuable comments and input were received from a number of people, including Igor Bryskin, Adrian Farrel, Ben Mack-Crane, Dimitri Papadimitriou, Fong Liaw and Juergen Heiles. Some sections of this document are based on text proposed by Fong Liaw.
多くの人々から貴重なコメントと入力を受け取りました、エードリアン・ファレル、ベンマック-クレーン、ディミトリPapadimitriou、フォンLiaw、およびユルゲンHeiles、イーゴリBryskinを含んでいて。 このドキュメントの数人のセクションがフォンLiawによって提案されたテキストに基づいています。
Berger Standards Track [Page 27] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[27ページ]RFC3471のGMPLSのシグナリングの機能的な記述
11. Security Considerations
11. セキュリティ問題
This document introduce no new security considerations to either [RFC3212] or [RFC3209]. The security considerations mentioned in [RFC3212] or [RFC3209] apply to the respective protocol specific forms of GMPLS, see [RFC3473] and [RFC3472].
このドキュメントは[RFC3212]か[RFC3209]のどちらかにどんな新しいセキュリティ問題も紹介しません。 [RFC3212]か[RFC3209]で言及されたセキュリティ問題はGMPLSの特定のフォームをそれぞれのプロトコルに適用します、と[RFC3473]と[RFC3472]は見ます。
12. IANA Considerations
12. IANA問題
The IANA will administer assignment of new values for namespaces defined in this document. This section uses the terminology of BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [BCP26].
IANAは本書では定義された名前空間のために新しい値の課題を管理するでしょう。 このセクションはBCP26の用語「RFCsにIANA問題部に書くためのガイドライン」[BCP26]を使用します。
This document defines the following namespaces:
このドキュメントは以下の名前空間を定義します:
o LSP Encoding Type: 8 bits
o Switching Type: 8 bits
o Generalized PID (G-PID): 16 bits
o Action: 8 bits
o Interface_ID Type: 16 bits
o タイプをコード化するLSP: 8ビットo Switching Type: 8ビットo Generalized PID(G-PID): 16ビットo Action: 8ビットo Interface_ID Type: 16ビット
All future assignments should be allocated through IETF Consensus action or documented in a Specification.
すべての将来の課題をIETF Consensus動作で割り当てるべきであるか、またはSpecificationに記録するべきです。
LSP Encoding Type - valid value range is 1-255. This document defines values 1-11.
LSP Encoding Type--有効値範囲は1-255です。 このドキュメントは値1-11を定義します。
Switching Type - valid value range is 1-255. This document defines values 1-4, 100, 150 and 200.
切り換えType--有効値範囲は1-255です。 このドキュメントは値1-4、100、150、および200を定義します。
Generalized PID (G-PID) - valid value range is 0-1500. This document defines values 0-46.
一般化されたPID(G-PID)--有効値範囲は0-1500です。 このドキュメントは値0-46を定義します。
Action - valid value range is 0-255. This document defines values 0-3.
動作--有効値範囲は0-255です。 このドキュメントは値0-3を定義します。
Interface_ID Type - valid value range is 1-65535. This document defines values 1-5.
インタフェース_ID Type--有効値範囲は1-65535です。 このドキュメントは値1-5を定義します。
Berger Standards Track [Page 28] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[28ページ]RFC3471のGMPLSのシグナリングの機能的な記述
13. Intellectual Property Considerations
13. 知的所有権問題
This section is taken from Section 10.4 of [RFC2026].
[RFC2026]のセクション10.4からこのセクションを取ります。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
14. References
14. 参照
14.1. Normative References
14.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.
and B. Thomas, "LDP Specification", RFC 3036,
January 2001.
[RFC3036] アンデションとL.とDoolanとP.とフェルドマンとN.とFredetteとA.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R.,
Wu, L., Doolan, P., Worster, T., Feldman, N.,
Fredette, A., Girish, M., Gray, E., Heinanen, J.,
Kilty, T. and A. Malis, "Constraint-Based LSP Setup
using LDP", RFC 3212, January 2002.
[RFC3212] Jamoussi、B.、アンデション、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、オースター、T.、フェルドマン、N.、Fredette、A.、Girish、M.、グレー、E.、Heinanen、J.、Kilty、T.、およびA.Malis、「自由民主党を使用して、規制ベースのLSPはセットアップします」、RFC3212、2002年1月。
Berger Standards Track [Page 29] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[29ページ]RFC3471のGMPLSのシグナリングの機能的な記述
[RFC3472] Ashwood-Smith, P. and L. Berger, Editors,
"Generalized Multi-Protocol Label Switching (GMPLS)
Signaling - Constraint-based Routed Label
Distribution Protocol (CR-LDP) Extensions", RFC
3472, January 2003.
[RFC3472]Ashwood-スミス、P.、およびL.バーガー、エディターズ、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング--規制ベースの発送されたラベル分配は拡大について議定書の中で述べ(CR-自由民主党)」、RFC3472、2003年1月。
[RFC3473] Berger, L., Editor "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling - Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003.
[RFC3473]バーガー、L.、エディタ、「マルチプロトコルで一般化されて、切り換え(GMPLS)をシグナリングとラベルしてください--資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、2003年1月。
14.2. Informative References
14.2. 有益な参照
[GMPLS-RTG] Kompella, K., et al., "Routing Extensions in Support
of Generalized MPLS", Work in Progress.
[GMPLS-RTG] Kompella、K.、他、「一般化されたMPLSを支持したルート設定拡大」、ProgressのWork。
[GMPLS-SONET] Ashwood-Smith, P., et al., "GMPLS - SONET / SDH
Specifics", Work in Progress.
[GMPLS-Sonet]Ashwood-スミス、P.、他、「GMPLS--、Sonet/SDH詳細、」、ProgressのWork。
[LMP] Lang, et al., "Link Management Protocol", Work in
Progress.
[LMP] ラング、他、「リンク管理プロトコル」、ProgressのWork。
[MPLS-BUNDLE] Kompella, K., Rekhter, Y. and L. Berger, "Link
Bundling in MPLS Traffic Engineering", Work in
Progress.
[MPLS-バンドル] 「MPLS交通工学におけるリンクバンドリング」というKompella、K.、Rekhter、Y.、およびL.バーガーは進行中で働いています。
[MPLS-HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with
MPLS TE", Work in Progress.
「MPLS TeがあるLSP階層構造」という[MPLS-階層構造]のKompella、K.、およびY.Rekhterは進行中で働いています。
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3," BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナー、S.、「インターネット規格は処理されます--改正3インチ、BCP9、RFC2026、10月1996日。
[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月)。
[RFC3031] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol label switching Architecture", RFC
3031, January 2001.
[RFC3031] ローゼンとE.とViswanathanとA.とR.Callon、「Multiprotocolラベル切り換えArchitecture」、RFC3031 2001年1月。
Berger Standards Track [Page 30] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[30ページ]RFC3471のGMPLSのシグナリングの機能的な記述
15. Contributors
15. 貢献者
Peter Ashwood-Smith Nortel Networks Corp. P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7 Canada
ピーターAshwood-スミスノーテルは社の私書箱3511駅C、オタワをK1Y 4H7カナダにネットワークでつなぎます。
Phone: +1 613 763 4534 EMail: petera@nortelnetworks.com
以下に電話をしてください。 +1 4534年の613 763メール: petera@nortelnetworks.com
Ayan Banerjee Calient Networks 5853 Rue Ferrari San Jose, CA 95138
アヤンバネルジーCalientネットワーク5853はフェラーリサンノゼ、カリフォルニア 95138を悔悟します。
Phone: +1 408 972-3645 EMail: abanerjee@calient.net
以下に電話をしてください。 +1 408 972-3645 メールしてください: abanerjee@calient.net
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
ルウバーガーMovazはInc.7926ジョーンズ支店ドライブスイート615マクリーン・ヴァージニア、22102をネットワークでつなぎます。
Phone: +1 703 847-1801 EMail: lberger@movaz.com
以下に電話をしてください。 +1 703 847-1801 メールしてください: lberger@movaz.com
Greg Bernstein
グレッグ・バーンスタイン
EMail: gregb@grotto-networking.com
メール: gregb@grotto-networking.com
John Drake Calient Networks 5853 Rue Ferrari San Jose, CA 95138
ジョンドレイクCalientネットワーク5853はフェラーリサンノゼ、カリフォルニア 95138を悔悟します。
Phone: +1 408 972 3720 EMail: jdrake@calient.net
以下に電話をしてください。 +1 3720年の408 972メール: jdrake@calient.net
Berger Standards Track [Page 31] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[31ページ]RFC3471のGMPLSのシグナリングの機能的な記述
Yanhe Fan Axiowave Networks, Inc. 200 Nickerson Road Marlborough, MA 01752
YanheファンAxiowaveはInc.200Nickerson Roadマールバラ、MA 01752をネットワークでつなぎます。
Phone: + 1 774 348 4627 EMail: yfan@axiowave.com
以下に電話をしてください。 4627がメールする+1 774 348: yfan@axiowave.com
Kireeti Kompella Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089
Kireeti Kompella杜松はInc.1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089
EMail: kireeti@juniper.net
メール: kireeti@juniper.net
Jonathan P. Lang EMail: jplang@ieee.org
ジョナサンP.ラングメール: jplang@ieee.org
Eric Mannie Independent Consultant 2 Avenue de la Folle Chanson 1050 Brussels Belgium EMail: eric_mannie@hotmail.com
エリックマニー無党派Consultant2アベニューde la Folle Chanson1050ブリュッセルベルギーEMail: eric_mannie@hotmail.com
Bala Rajagopalan Tellium, Inc. 2 Crescent Place P.O. Box 901 Oceanport, NJ 07757-0901
私書箱901Oceanport、Bala Rajagopalan Tellium Inc.2の三日月形Placeニュージャージー07757-0901
Phone: +1 732 923 4237 Fax: +1 732 923 9804 EMail: braja@tellium.com
以下に電話をしてください。 +1 732 923、4237Fax: +1 9804年の732 923メール: braja@tellium.com
Yakov Rekhter Juniper Networks, Inc.
ヤコフRekhter JuniperはInc.をネットワークでつなぎます。
EMail: yakov@juniper.net
メール: yakov@juniper.net
Berger Standards Track [Page 32] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[32ページ]RFC3471のGMPLSのシグナリングの機能的な記述
Debanjan Saha EMail: debanjan@acm.org
DebanjanシャハEMail: debanjan@acm.org
Vishal Sharma Metanoia, Inc. 1600 Villa Street, Unit 352 Mountain View, CA 94041-1174 Phone: +1 650-386-6723 EMail: v.sharma@ieee.org
VishalシャルマMetanoia, Inc.1600Villa通り、Unit352マウンテンビュー、カリフォルニア94041-1174は以下に電話をします。 +1 650-386-6723 メールしてください: v.sharma@ieee.org
George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824
ジョージツバメシスコシステムズInc.250アポロDriveチェルムズフォード、MA 01824
Phone: +1 978 244 8143 EMail: swallow@cisco.com
以下に電話をしてください。 +1 8143年の978 244メール: swallow@cisco.com
Z. Bo Tang EMail: botang01@yahoo.com
Z.棒ピリッとする味メール: botang01@yahoo.com
16. Editor's Address
16. エディタのアドレス
Lou Berger Movaz Networks, Inc. 7926 Jones Branch Drive Suite 615 McLean VA, 22102
ルウバーガーMovazはInc.7926ジョーンズ支店ドライブスイート615マクリーン・ヴァージニア、22102をネットワークでつなぎます。
Phone: +1 703 847-1801 EMail: lberger@movaz.com
以下に電話をしてください。 +1 703 847-1801 メールしてください: lberger@movaz.com
Berger Standards Track [Page 33] RFC 3471 GMPLS Signaling Functional Description
バーガー標準化過程[33ページ]RFC3471のGMPLSのシグナリングの機能的な記述
17. Full Copyright Statement
17. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Berger Standards Track [Page 34]
バーガー標準化過程[34ページ]
一覧
スポンサーリンク
