diff options
Diffstat (limited to 'doc/rfc/rfc7581.txt')
| -rw-r--r-- | doc/rfc/rfc7581.txt | 2075 |
1 files changed, 2075 insertions, 0 deletions
diff --git a/doc/rfc/rfc7581.txt b/doc/rfc/rfc7581.txt new file mode 100644 index 0000000..48095d5 --- /dev/null +++ b/doc/rfc/rfc7581.txt @@ -0,0 +1,2075 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Bernstein, Ed. +Request for Comments: 7581 Grotto Networking +Category: Standards Track Y. Lee, Ed. +ISSN: 2070-1721 D. Li + Huawei + W. Imajuku + NTT + J. Han + Huawei + June 2015 + + + Routing and Wavelength Assignment Information Encoding for + Wavelength Switched Optical Networks + +Abstract + + A Wavelength Switched Optical Network (WSON) requires certain key + information fields be made available to facilitate path computation + and the establishment of Label Switched Paths (LSPs). The + information model described in "Routing and Wavelength Assignment + Information Model for Wavelength Switched Optical Networks" (RFC + 7446) shows what information is required at specific points in the + WSON. Part of the WSON information model contains aspects that may + be of general applicability to other technologies, while other parts + are specific to WSONs. + + This document provides efficient, protocol-agnostic encodings for the + WSON-specific information fields. It is intended that protocol- + specific documents will reference this memo to describe how + information is carried for specific uses. Such encodings can be used + to extend GMPLS signaling and routing protocols. In addition, these + encodings could be used by other mechanisms to convey this same + information to a Path Computation Element (PCE). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7581. + + + +Bernstein, et al. Standards Track [Page 1] + +RFC 7581 WSON Information Encoding June 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bernstein, et al. Standards Track [Page 2] + +RFC 7581 WSON Information Encoding June 2015 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Terminology ................................................4 + 1.2. Conventions Used in This Document ..........................5 + 2. Resources, Resource Blocks, and the Resource Pool ...............5 + 2.1. Resource Block Set Field ...................................6 + 3. Resource Accessibility/Availability .............................7 + 3.1. Resource Accessibility Field ...............................7 + 3.2. Resource Wavelength Constraints Field ......................9 + 3.3. Resource Block Pool State Field ...........................10 + 3.4. Resource Block Shared Access Wavelength + Availability Field ........................................12 + 4. Resource Block Information Field ...............................13 + 4.1. Optical Interface Class List Subfield .....................15 + 4.1.1. ITU-T G.698.1 Application Code Mapping .............17 + 4.1.2. ITU-T G.698.2 Application Code Mapping .............18 + 4.1.3. ITU-T G.959.1 Application Code Mapping .............20 + 4.1.4. ITU-T G.695 Application Code Mapping ...............22 + 4.2. Acceptable Client Signal List Subfield ....................23 + 4.3. Input Bit Rate List Subfield ..............................24 + 4.4. Processing Capability List Subfield .......................24 + 5. Security Considerations ........................................26 + 6. IANA Considerations ............................................26 + 6.1. Types for Subfields of WSON Resource Block Information ....26 + 7. References .....................................................27 + 7.1. Normative References ......................................27 + 7.2. Informative References ....................................28 + Appendix A. Encoding Examples .....................................30 + A.1. Wavelength Converter Accessibility Field ..................30 + A.2. Wavelength Conversion Range Field .........................32 + A.3. An OEO Switch with DWDM Optics ............................32 + Contributors ......................................................35 + Authors' Addresses ................................................37 + + + + + + + + + + + + + + + + + +Bernstein, et al. Standards Track [Page 3] + +RFC 7581 WSON Information Encoding June 2015 + + +1. Introduction + + A Wavelength Switched Optical Network (WSON) is a Wavelength Division + Multiplexing (WDM) optical network in which switching is performed + selectively based on the center wavelength of an optical signal. + + [RFC6163] describes a framework for Generalized Multiprotocol Label + Switching (GMPLS) and Path Computation Element (PCE) control of a + WSON. Based on this framework, [RFC7446] describes an information + model that specifies what information is needed at various points in + a WSON in order to compute paths and establish Label Switched Paths + (LSPs). + + This document provides efficient encodings of information needed by + the Routing and Wavelength Assignment (RWA) process in a WSON. Such + encodings can be used to extend GMPLS signaling and routing + protocols. In addition, these encodings could be used by other + mechanisms to convey this same information to a PCE. Note that since + these encodings are efficient, they can provide more accurate + analysis of the control-plane communications/processing load for + WSONs looking to utilize a GMPLS control plane. + + In parallel to this document, [RFC7579] provides efficient encodings + of information needed by the routing and label assignment process + that are potentially applicable to a wider range of technologies. + +1.1. Terminology + + Refer to [RFC6163] for definitions of the following: + + o Coarse Wavelength Division Multiplexing (CWDM) + + o Dense Wavelength Division Multiplexing (DWDM) + + o Routing and Wavelength Assignment (RWA) + + o Wavelength Division Multiplexing (WDM) + + Refer to Section 5 of [RFC7446] for definitions of the following: + + o resource + + o resource block + + o resource pool + + + + + + +Bernstein, et al. Standards Track [Page 4] + +RFC 7581 WSON Information Encoding June 2015 + + + The Optical Interface (OI) Code Point is a unique number that + identifies all information related to optical characteristics of a + physical interface. + +1.2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Resources, Resource Blocks, and the Resource Pool + + This section provides encodings for the information fields defined in + [RFC7446] that have applicability to WSON. The encodings are + designed to be suitable for use in the GMPLS routing protocols OSPF + [RFC4203] and IS-IS [RFC5307] and in the PCE Communication Protocol + (PCEP) [RFC5440]. Note that the information distributed in [RFC4203] + and [RFC5307] is arranged via the nesting of sub-TLVs within TLVs; + this document defines elements to be used within such constructs. + Specific constructs of sub-TLVs and the nesting of sub-TLVs of the + information fields defined by this document will be defined in the + respective protocol enhancement documents. + + This document defines the following information fields pertaining to + resources within an optical node: + + o Resource Accessibility <ResourceAccessibility> + + o Resource Wavelength Constraints <ResourceWaveConstraints> + + o Resource Block Pool State <RBPoolState> + + o Resource Block Shared Access Wavelength Availability + <RBSharedAccessWaveAvailability> + + o Resource Block Information <ResourceBlockInfo> + + Each of these information fields works with one or more sets of + resources rather than just a single resource block. This motivates + the field definition in Section 2.1. + + + + + + + + + + + +Bernstein, et al. Standards Track [Page 5] + +RFC 7581 WSON Information Encoding June 2015 + + +2.1. Resource Block Set Field + + In a WSON node that includes resource blocks (RBs), denoting subsets + of these blocks allows one to efficiently describe common properties + of the blocks and to describe the structure and characteristics, if + nontrivial, of the resource pool. The Resource Block Set (RB Set) + Field is defined in a similar manner to the label set concept of + [RFC3471]. + + The information carried in an RB Set Field is defined as follows: + + 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 |C| Reserved | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Identifier 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Identifier n | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Action: 8 bits + + 0 - Inclusive List + + Indicates that the TLV contains one or more RB elements that + are included in the list. + + 1 - Inclusive Range(s) + + Indicates that the TLV contains one or more ranges of RBs. + Each individual range is denoted by two 32-bit RB identifiers. + The first 32 bits is the RB identifier for the start of the + range, and the next 32 bits is the RB identifier for the end + of the range. Note that the Length field is used to determine + the number of ranges. + + C (Connectivity bit) + + Set to 0 to denote fixed (possibly multicast) connectivity, and + set to 1 to denote potential (switched) connectivity. Used in + Resource Accessibility field. Ignored elsewhere. + + + + + + + +Bernstein, et al. Standards Track [Page 6] + +RFC 7581 WSON Information Encoding June 2015 + + + Reserved: 7 bits + + This field is reserved. It MUST be set to zero on transmission + and MUST be ignored on receipt. + + Length: 16 bits + + The total length of this field in bytes. + + RB Identifier: + + The RB identifier represents the ID of the resource block, which + is a 32-bit integer. The scope of the RB identifier is local to + the node on which it is applied. + + Usage Note: The inclusive range "Action" can result in very compact + encoding of resource sets, and it can be advantageous to number + resource blocks in such a way so that status updates (dynamic + information) can take advantage of this efficiency. + +3. Resource Accessibility/Availability + + This section defines the information fields for dealing with + accessibility and availability of resource blocks within a pool of + resources. These include the <ResourceAccessibility>, + <ResourceWaveConstraints>, <RBPoolState>, and + <RBSharedAccessWaveAvailability> fields. + +3.1. Resource Accessibility Field + + This information field describes the structure of the resource pool + in relation to the switching device. In particular, it indicates the + ability of an input port to reach sets of resources and the ability + of sets of resources to reach a particular output port. This is the + <PoolInputMatrix> and <PoolOutputMatrix> of [RFC7446]. + + + + + + + + + + + + + + + + +Bernstein, et al. Standards Track [Page 7] + +RFC 7581 WSON Information Encoding June 2015 + + + The Resource Accessibility field is defined as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Reserved(8bits)|C| Reserved (23 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Link Set Field A #1 | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Set Field A #1 | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Additional Link set and RB set pairs as needed to | + : specify PoolInputMatrix : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Link Set Field B #1 | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Set B Field #1 (for output connectivity) | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Additional Link Set and RB set pairs as needed to | + : specify PoolOutputMatrix : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Where: + + C (Connectivity bit): Connectivity indicates how the input/output + ports connect to the resource blocks. + + 0 - the device is fixed (e.g., a connected port must go through + the resource block) + + 1 - the device is switched (e.g., a port can be configured to go + through a resource but isn't required) + + For the Input and Output Link Set Fields, the Link Set Field encoding + defined in [RFC7579] is to be used. + + Note that the direction parameter within the Link Set Field is used + to indicate whether the link set is an input or output link set, and + the bidirectional value for this parameter is not permitted in this + field. + + See Appendix A.1 for an illustration of this encoding. + + + + + +Bernstein, et al. Standards Track [Page 8] + +RFC 7581 WSON Information Encoding June 2015 + + +3.2. Resource Wavelength Constraints Field + + Resources, such as wavelength converters, etc., may have limited + input or output wavelength ranges. Additionally, due to the + structure of the optical system, not all wavelengths can necessarily + reach or leave all the resources. These properties are described by + using one or more Resource Wavelength Constraints fields as defined + below: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I|O|B| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Set Field | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Wavelength Constraints | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Wavelength Constraints | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + I (Input): + + 1 - indicates the presence of the Input Wavelength Constraints + field + + 0 - indicates otherwise. + + O (Output): + + 1 - indicates the presence of the Output Wavelength Constraints + field + + 0 - indicates otherwise. + + B (Both): + + 1 - indicates that a single Wavelength Constraints field + represents both Input and Output Wavelength Constraints + fields. + + Currently, the only valid combinations of (I,O,B) are (1,0,0), + (0,1,0), (1,1,0), and (0,0,1). + + + + + +Bernstein, et al. Standards Track [Page 9] + +RFC 7581 WSON Information Encoding June 2015 + + + RB Set Field: + + A set of resource blocks (RBs) that have the same wavelength + restrictions. + + Input Wavelength Constraints: + + Indicates the wavelength input restrictions of the RBs in the + corresponding RB set. This field is encoded via the Label Set + Field of [RFC7579]. + + Output Wavelength Constraints: + + Indicates the wavelength output restrictions of RBs in the + corresponding RB set. This field is encoded via the Label Set + Field of [RFC7579]. + +3.3. Resource Block Pool State Field + + The state of the pool is given by the number of resources available + with particular characteristics. A resource block set is used to + encode all or a subset of the resources of interest. The usage state + of resources within a resource block set is encoded as either a list + of 16-bit integer values or a bitmap indicating whether a single + resource is available or in use. The bitmap encoding is appropriate + when resource blocks consist of a single resource. This information + can be relatively dynamic, i.e., can change when a connection (LSP) + is established or torn down. + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Set Field | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Usage State | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Where: + + Action = 0 denotes a list of 16-bit integers, and Action = 1 denotes + a bitmap. Action = 0 covers the case where there are multiple + elements for each resource block. Action = 1 covers the case where + each resource block only contains a single element. + + + + +Bernstein, et al. Standards Track [Page 10] + +RFC 7581 WSON Information Encoding June 2015 + + + In both cases, the elements of the RB Set Field are in a one-to-one + correspondence with the values in the RB Usage State area. + + 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 = 0 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Set Field | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB#1 State | RB#2 State | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB#n-1 State | RB#n State or Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + RB#i State (16 bits, unsigned integer): Indicates the number of + resources available in Resource Block #i. + + Whether the last 16 bits is a wavelength converter (RB) state or + padding is determined by the number of elements in the RB Set Field. + + 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 = 1 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Set Field | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Usage State Bitmap | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ...... | Padding Bits | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + RB Usage State Bitmap: Variable length but must be a multiple of 4 + bytes. + + Each bit indicates the usage status of one RB with 0 indicating the + RB is available and 1 indicating the RB is in use. The sequence of + the bitmap is ordered according to the RB Set Field with this + element. + + Padding bits: Variable length + + + + +Bernstein, et al. Standards Track [Page 11] + +RFC 7581 WSON Information Encoding June 2015 + + +3.4. Resource Block Shared Access Wavelength Availability Field + + Resource blocks may be accessed via a shared fiber. If this is the + case, then wavelength availability on these shared fibers is needed + to understand resource availability. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I|O|B| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Set Field | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Available Wavelength Set Field | + : (Optional) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Available Wavelength Set Field | + : (Optional) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + I (Input): + + 1 - indicates the presence of the Input Available Wavelength Set + Field. + + 0 - indicates the absence of the Input Available Wavelength Set + Field. + + O (Output): + + 1 - indicates the presence of the Output Available Wavelength Set + Field. + + 0 - indicates the absence of the Output Available Wavelength Set + Field. + + B (Both): + + 1 - indicates that a single Available Wavelength Set Field + represents both Input and Output Available Wavelength Set + Fields. + + Currently, the only valid combinations of (I,O,B) are (1,0,0), + (0,1,0), (1,1,0), and (0,0,1). + + + + + + +Bernstein, et al. Standards Track [Page 12] + +RFC 7581 WSON Information Encoding June 2015 + + + RB Set Field: + + A resource block set in which all the members share the same input + or output fiber or both. + + Input Available Wavelength Set Field: + + Indicates the wavelengths currently available (not being used) on + the input fiber to this resource block. This field is encoded via + the Label Set Field of [RFC7579]. + + Output Available Wavelength Set Field: + + Indicates the wavelengths currently available (not being used) on + the output fiber from this resource block. This field is encoded + via the Label Set Field of [RFC7579]. + +4. Resource Block Information Field + + As defined in [RFC7446], the Resource Block Information + <ResourceBlockInfo> field is used to represent resource signal + constraints and processing capabilities of a node. + + The fundamental properties of a resource block are: + + o Optical Interface Class List(s) + + o Acceptable Client Signal (shared input, modulation, Forward Error + Correction (FEC), bit rate, and Generalized Protocol Identifier + (G-PID)) + + o Input Bit Rate + + o Processing Capabilities (number of resources in a block, + regeneration, performance monitoring, vendor specific) + + <ResourceBlockInfo> fields are used to convey relatively static + information about individual resource blocks, including the resource + block properties and the number of resources in a block. + + When more than one <ResourceBlockInfo> field is used, there are no + ordering requirements amongst these fields. The length of the + <ResourceBlockInfo> field is determined from the length of the object + that includes it. + + + + + + + +Bernstein, et al. Standards Track [Page 13] + +RFC 7581 WSON Information Encoding June 2015 + + + The <ResourceBlockInfo> field 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Set Field | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I|O|B| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Optional Subfield 1 | + : ... : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : : + : : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Optional Subfield N | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The RB Set Field is described in Section 2.1. + + The shared input or output indication is indicated by the first bit + (I), the second bit (O), and the third bit (B). + + I (Input): + + 1 - indicates if the resource blocks identified in the RB Set + Field utilized a shared fiber for input access. + + 0 - indicates otherwise. + + O (Output): + + 1 - indicates if the resource blocks identified in the RB Set + Field utilized a shared fiber for output access. + + 0 - indicates otherwise. + + B (Both): + + 1 - indicates if the resource blocks identified in the RB Set + Field utilized a shared fiber for both input and output + access. + + 0 - indicates otherwise. + + + + + +Bernstein, et al. Standards Track [Page 14] + +RFC 7581 WSON Information Encoding June 2015 + + + Currently, the only valid combinations of (I,O,B) are (1,0,0), + (0,1,0), (1,1,0), and (0,0,1). + + Zero or more Optional Subfields MAY be present. Optional Subfields + have 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value... | + . . + . . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Length field defines the length of the value portion in bytes + (thus, a subfield with no value portion would have a length of zero). + The subfield is padded to 4-byte alignment; padding is not included + in the Length field (so a 3-byte value would have a length of three, + but the total size of the subfield would be 8 bytes). Unrecognized + types are not processed. If multiple subfields of the same type are + present, only the first of the type SHOULD be processed. + + The following sub-TLV types are defined: + + Value Length Sub-TLV Type + + 1 variable Optical Interface Class List + 2 variable Acceptable Client Signal List + 3 variable Input Bit Rate List + 4 variable Processing Capability List + + See the IANA Considerations section for allocation of new types. + +4.1. Optical Interface Class List Subfield + + The Optical Interface Class List subfield 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved |I|O| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Optical Interface Classes | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Bernstein, et al. Standards Track [Page 15] + +RFC 7581 WSON Information Encoding June 2015 + + + The following I and O combination are defined: + + I O + ----- + 0 0 Invalid + + 1 0 Optical Interface Class List acceptable in input + + 0 1 Optical Interface Class List available in output + + 1 1 Optical Interface Class List available on both input and + output. + + The resource block MAY contain one or more lists according to the + input/output flags. + + The Optical Interface Classes format is defined as follows: + + 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 | OI Code Points | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Optical Interface Class | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Optical Interface Class (Cont.) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Where the first 32 bits of the encoding shall be used to identify the + semantics of the Optical Interface Class in the following way: + + S (Standard bit): + + S=0: identifies non-ITU code points + + S=1: identifies ITU application codes + + With S=0, the OI Code Points field can take the following value: + + 0: reserved + + Future work may add support for vendor-specific application codes + once the ITU-T has completed its work in that area. + + + + + + + + +Bernstein, et al. Standards Track [Page 16] + +RFC 7581 WSON Information Encoding June 2015 + + + With S=1, the OI Code Points field can take the following values: + + 0: reserved + + 1: [G.698.1] application code + + 2: [G.698.2] application code + + 3: [G.959.1] application code + + 4: [G.695] application code + + In the case of ITU application codes, the mapping between the string + defining the application code and the 64 bits implementing the + optical interface class is given in the following sections. + +4.1.1. ITU-T G.698.1 Application Code Mapping + + [G.698.1] defines the following application codes: DScW-ytz(v) and + B-DScW-ytz(v). Where: + + B: means Bidirectional + + D: means a DWDM application + + S: takes values N (narrow spectral excursion) or W (wide spectral + excursion) + + c: Channel Spacing (GHz) + + W: takes values S (short-haul) or L (long-haul) + + y: takes values 1 (NRZ 2.5G) or 2 (NRZ 10G) + + t: only D value is defined (link does not contain optical + amplifier) + + z: takes values 2 ([G.652] fibre), 3 ([G.653] fibre), or 5 + ([G.655] fibre) + + v: takes values S (Short wavelength), C (Conventional), or L (Long + wavelength) + + The F flag indicates the presence or absence of an optional FEC + encoding suffix. + + + + + + +Bernstein, et al. Standards Track [Page 17] + +RFC 7581 WSON Information Encoding June 2015 + + + These get mapped into the 64-bit Optical Interface Class field as + follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |B| D |S| c | W | y | t | z | v | F | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Where (values between parentheses refer to ITU-defined values as + reported above): + + B: 1 bidirectional, 0 otherwise + + D (prefix): 0 reserved, 1 (D) + + S: 0 (N), 1 (W) + + c: Channel Spacing, 4 bits mapped according to the same definition + as in the third figure in Section 3.2 of [RFC6205] (note that + DWDM spacing applies here). + + W: 0 reserved, 2 (S), 3 (L) + + y: 0 reserved, 1 (1), 2 (2) + + t: 0 reserved, 4 (D) + + z: 0 reserved, 2 (2), 3 (3), 5 (5) + + v: 0 reserved, 1 (S), 2 (C), 3 (L) + + F (suffix): 0 No FEC encoding suffix present, 1 FEC encoding + suffix present + + Values not mentioned here are not allowed in this application code; + the last 32 bits are reserved and shall be set to zero. + +4.1.2. ITU-T G.698.2 Application Code Mapping + + [G.698.2] defines the following application codes: DScW-ytz(v) and + B-DScW-ytz(v). Where: + + B: means Bidirectional + + D: means a DWDM application + + + +Bernstein, et al. Standards Track [Page 18] + +RFC 7581 WSON Information Encoding June 2015 + + + S: takes values N (narrow spectral excursion) or W (wide spectral + excursion) + + c: Channel Spacing (GHz) + + W: takes values C (link is dispersion compensated) or U (link is + dispersion uncompensated) + + y: takes values 1 (NRZ 2.5G) or 2 (NRZ 10G) + + t: takes value A (link may contains optical amplifier) + + z: takes values 2 ([G.652] fibre), 3 ([G.653] fibre), or 5 + ([G.655] fibre) + + v: takes values S (Short wavelength), C (Conventional), or L (Long + wavelength) + + An optional F can be added to indicate a FEC encoding. + + These get mapped into the 64-bit Optical Interface Class field as + follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |B| D |S| c | W | y | t | z | v | F | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Where (values between parentheses refer to ITU-defined values as + reported above): + + B: 1 bidirectional, 0 otherwise + + D (prefix): 0 reserved, 1 (D) + + S: 0 (N), 1 (W) + + c: Channel Spacing, 4 bits mapped according to the same definition + as in the third figure in Section 3.2 of [RFC6205] (note that + DWDM spacing applies here). + + W: 0 reserved, 10 (C), 11 (U) + + y: 0 reserved, 1 (1), 2 (2) + + + + +Bernstein, et al. Standards Track [Page 19] + +RFC 7581 WSON Information Encoding June 2015 + + + t: 0 reserved, 1 (A) + + z: 0 reserved, 2 (2), 3 (3), 5 (5) + + v: 0 reserved, 1 (S), 2 (C), 3 (L) + + F (suffix): 0 reserved, 1 FEC encoding + + Values not mentioned here are not allowed in this application code. + The last 32 bits are reserved and shall be set to zero. + +4.1.3. ITU-T G.959.1 Application Code Mapping + + [G.959.1] defines the following application codes: PnWx-ytz and + BnWx-ytz. Where: + + P,B: when present, indicate Plural or Bidirectional + + n: maximum number of channels supported by the application code + (i.e., an integer number) + + W: takes values I (intra-office), S (short-haul), L (long-haul), V + (very long-haul), or U (ultra long-haul) + + x: maximum number of spans allowed within the application code + (i.e., an integer number) + + y: takes values 1 (NRZ 2.5G), 2 (NRZ 10G), 9 (NRZ 25G), 3 (NRZ + 40G), or 7 (RZ 40G) + + t: takes values A (power levels suitable for a booster amplifier + in the originating ONE and power levels suitable for a pre- + amplifier in the terminating ONE), B (booster amplifier only), + C (pre-amplifier only), or D (no amplifiers) + + z: takes values 1 (1310 nm sources on [G.652] fibre), 2 (1550 nm + sources on [G.652] fibre), 3 (1550 nm sources on [G.653] + fibre), or 5 (1550 nm sources on [G.655] fibre). + + The following list of suffixes can be added to these application + codes: + + F: FEC encoding + + D: Adaptive dispersion compensation + + E: receiver capable of dispersion compensation + + + + +Bernstein, et al. Standards Track [Page 20] + +RFC 7581 WSON Information Encoding June 2015 + + + r: reduced target distance + + a: power levels appropriate to APD receivers + + b: power levels appropriate to PIN receivers + + These values are encoded as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | p | P | n | W | x | reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | y | t | z | suffix | reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Where (values between parentheses refer to ITU-defined values as + reported above): + + p (prefix): 0 otherwise, 1 Bidirectional (B) + + P (optional): 0 not present, 2 (P). + + n: maximum number of channels (10 bits, up to 1023 channels) + + W: 0 reserved, 1 (I), 2 (S), 3 (L), 4 (V), 5 (U) + + x: number of spans (6 bits, up to 64 spans) + + y: 0 reserved, 1 (1), 2 (2), 3 (3), 7 (7), 9 (9) + + t: 0 reserved, 1 (A), 2 (B), 3 (C), 4 (D) + + z: 0 reserved, 1 (1), 2 (2), 3 (3), 5 (5) + + suffix: a 6-bit bitmap, where a "1" in the appropriate slot + indicates that the corresponding suffix has been added. + + 0 1 2 3 4 5 + +-+-+-+-+-+-+ + |F|D|E|r|a|b| + +-+-+-+-+-+-+ + + + + + + + + + +Bernstein, et al. Standards Track [Page 21] + +RFC 7581 WSON Information Encoding June 2015 + + +4.1.4. ITU-T G.695 Application Code Mapping + + [G.695] defines the following application codes: CnWx-ytz, + B-CnWx-ytz, and S-CnWx-ytz. + + Where the optional prefixes are: + + B: Bidirectional + + S: a system using a black link approach + + And the rest of the application code is defined as: + + C: CWDM (Coarse WDM) application + + n: maximum number of channels supported by the application code + (i.e., an integer number) + + W: takes values S (short-haul) or L (long-haul) + + x: maximum number of spans allowed + + y: takes values 0 (NRZ 1.25G), 1 (NRZ 2.5G), or 2 (NRZ 10G). + + t: takes value D (link does not contain any optical amplifier). + + z: takes values 1 (1310 nm region for [G.652] fibre), 2 (ITU-T + [G.652] fibre), 3 ([G.653] fibre), or 5 ([G.655] fibre) + + The following list of suffixes can be added to these application + codes: + + F: FEC encoding + + Since the application codes are very similar to the ones from the + [G.959.1] section, most of the fields are reused. The 64-bit Optical + Interface Class field is encoded as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | p | C | n | W | x | reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | y | t | z | suffix | reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Bernstein, et al. Standards Track [Page 22] + +RFC 7581 WSON Information Encoding June 2015 + + + Where (values between parentheses refer to ITU-defined values as + reported above): + + p: 0 no prefix, 1 (B) bidirectional, 2 (S) black link + + C: 0 reserved, 3 (C) + + n: maximum number of channels (10 bits, up to 1023 channels) + + W: 0 reserved, 1 reserved, 2 (S), 3 (L), > 3 reserved + + x: number of spans (6 bits, up to 64 spans) + + y: 0 (0), 1 (1), 2 (2), > 2 reserved + + t: 4 (D), all other values are reserved + + z: 0 reserved, 1 (1), 2 (2), 3 (3) + + suffix: a 6-bit bitmap, where a "1" in the appropriate slot + indicates that the corresponding suffix has been added. + + 0 1 2 3 4 5 + +-+-+-+-+-+-+ + |F|0|0|0|0|0| + +-+-+-+-+-+-+ + +4.2. Acceptable Client Signal List Subfield + + This subfield contains a list of acceptable input client signal + types. + + The acceptable client signal list is a list of Generalized Protocol + Identifiers (G-PIDs). + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Number of G-PIDs | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | G-PID #1 | G-PID #2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : | : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | G-PID #N | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Bernstein, et al. Standards Track [Page 23] + +RFC 7581 WSON Information Encoding June 2015 + + + Number of G-PIDs: an integer greater than or equal to one. + + G-PIDs: assigned by IANA. Many are defined in [RFC3471] and + [RFC4328]. + +4.3. Input Bit Rate List Subfield + + This subfield contains a list of bit rates of each input client + signal type specified in the Input Client Signal List. + + The number of Input Bit Rates MUST match the number of G-PIDs. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Bit Rate of G-PID #1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Bit Rate of G-PID #N | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Input Bit Rates are in IEEE 754 floating point format [IEEE]. + +4.4. Processing Capability List Subfield + + The Processing Capability List subfield is a list of capabilities + that can be achieved through the referred resources: + + 1. Regeneration capability + + 2. Fault and performance monitoring + + 3. Vendor-specific capability + + Fault and performance monitoring and vendor-specific capability have + no additional capability parameters. + + + + + + + + + + + + + + +Bernstein, et al. Standards Track [Page 24] + +RFC 7581 WSON Information Encoding June 2015 + + + The Processing Capability List subfield is defined as: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Processing Cap ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Possible additional capability parameters depending upon | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : the processing ID : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Processing Cap ID field defines the following processing + capabilities: + + 0: Reserved + + 1: Regeneration capability + + 2: Fault and performance monitoring + + 3: Vendor-specific capability + + When the Processing Cap ID is "Regeneration capability", the + following additional capability parameters are provided in the + following field: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | T | C | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Where the T bit indicates the type of regenerator: + + T=0: Reserved + + T=1: 1R Regenerator + + T=2: 2R Regenerator + + T=3: 3R Regenerator + + + + + + + + + +Bernstein, et al. Standards Track [Page 25] + +RFC 7581 WSON Information Encoding June 2015 + + + And where the C bit indicates the capability of the regenerator: + + C=0: Reserved + + C=1: Fixed Regeneration Point + + C=2: Selective Regeneration Pools + + Note that when the capability of the regenerator is indicated to be + "Selective Regeneration Pools", regeneration pool properties such as + input and output restrictions and availability need to be specified. + These properties will be encoded in the field providing additional + capability parameters, starting with the bits marked Reserved in the + figure immediately above. An additional specification describing the + encoding of these parameters is required before the value C=2 can be + used. + +5. Security Considerations + + This document defines protocol-independent encodings for WSON + information and does not introduce any security issues. + + However, other documents that make use of these encodings within + protocol extensions need to consider the issues and risks associated + with inspection, interception, modification, or spoofing of any of + this information. It is expected that any such documents will + describe the necessary security measures to provide adequate + protection. A general discussion on security in GMPLS networks can + be found in [RFC5920]. + +6. IANA Considerations + + This document introduces a new top-level registry for GMPLS routing + parameters for WSON encoding. This new IANA registry has been + created to make the assignment of a new type and new values for the + new "GMPLS Routing Parameters for WSON" registry. Note that this + registry is only used in routing, not in signaling. + +6.1. Types for Subfields of WSON Resource Block Information + + Under the new "GMPLS Routing Parameters for WSON" registry, a new + IANA subregistry has been created for nested subfields of the + Resource Block Information field to create a new section named "Types + for Subfields of WSON Resource Block Information Registry". This + registry will be maintained via Standards Action as defined by + [RFC5226]. + + + + + +Bernstein, et al. Standards Track [Page 26] + +RFC 7581 WSON Information Encoding June 2015 + + + The initial values in the registry are as follows: + + Value Length Description Reference + ----- ------ ------------ --------- + 0 Reserved + 1 variable Optical Interface Class List [RFC7581] + 2 variable Acceptable Client Signal List [RFC7581] + 3 variable Input Bit Rate List [RFC7581] + 4 variable Processing Capability List [RFC7581] + 5-65535 Unassigned + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Extensions for G.709 Optical + Transport Networks Control", RFC 4328, + DOI 10.17487/RFC4328, January 2006, + <http://www.rfc-editor.org/info/rfc4328>. + + [RFC6205] Otani, T., Ed., and D. Li, Ed., "Generalized Labels for + Lambda-Switch-Capable (LSC) Label Switching Routers", + RFC 6205, DOI 10.17487/RFC6205, March 2011, + <http://www.rfc-editor.org/info/rfc6205>. + + [RFC7446] Lee, Y., Ed., Bernstein, G., Ed., Li, D., and W. Imajuku, + "Routing and Wavelength Assignment Information Model for + Wavelength Switched Optical Networks", RFC 7446, + DOI 10.17487/RFC7446, February 2015, + <http://www.rfc-editor.org/info/rfc7446>. + + [RFC7579] Bernstein, G., Ed., Lee, Y., Ed., Li, D., Imajuku, W., and + J. Han, "General Network Element Constraint Encoding for + GMPLS-Controlled Networks", RFC 7579, + DOI 10.17487/RFC7579, June 2015, + <http://www.rfc-editor.org/info/rfc7579>. + + + + + + + + + +Bernstein, et al. Standards Track [Page 27] + +RFC 7581 WSON Information Encoding June 2015 + + +7.2. Informative References + + [G.652] ITU-T, "Characteristics of a single-mode optical fibre and + cable", ITU-T Recommendation G.652, November 2009. + + [G.653] ITU-T, "Characteristics of a dispersion-shifted, single- + mode optical fibre and cable", ITU-T Recommendation G.653, + July 2010. + + [G.655] ITU-T, "Characteristics of a non-zero dispersion-shifted + single-mode optical fibre and cable", ITU-T Recommendation + G.655, November 2009. + + [G.695] ITU-T, "Optical interfaces for coarse wavelength division + multiplexing applications", ITU-T Recommendation G.695, + January 2015. + + [G.698.1] ITU-T, "Multichannel DWDM applications with single-channel + optical interfaces", ITU-T Recommendation G.698.1, + November 2009. + + [G.698.2] ITU-T, "Amplified multichannel dense wavelength division + multiplexing applications with single channel optical + interfaces", ITU-T Recommendation G.698.2, November 2009. + + [G.959.1] ITU-T, "Optical transport network physical layer + interfaces", ITU-T Recommendation G.959.1, February 2012. + + [IEEE] IEEE, "IEEE Standard for Binary Floating-Point + Arithmetic", IEEE Standard 754. + + [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Functional Description", + RFC 3471, DOI 10.17487/RFC3471, January 2003, + <http://www.rfc-editor.org/info/rfc3471>. + + [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions + in Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, + <http://www.rfc-editor.org/info/rfc4203>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + + + + + +Bernstein, et al. Standards Track [Page 28] + +RFC 7581 WSON Information Encoding June 2015 + + + [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions + in Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, + <http://www.rfc-editor.org/info/rfc5307>. + + [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol (PCEP)", RFC 5440, + DOI 10.17487/RFC5440, March 2009, + <http://www.rfc-editor.org/info/rfc5440>. + + [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax + Used to Form Encoding Rules in Various Routing Protocol + Specifications", RFC 5511, DOI 10.17487/RFC5511, April + 2009, <http://www.rfc-editor.org/info/rfc5511>. + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, + <http://www.rfc-editor.org/info/rfc5920>. + + [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, + "Framework for GMPLS and Path Computation Element (PCE) + Control of Wavelength Switched Optical Networks (WSONs)", + RFC 6163, DOI 10.17487/RFC6163, April 2011, + <http://www.rfc-editor.org/info/rfc6163>. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bernstein, et al. Standards Track [Page 29] + +RFC 7581 WSON Information Encoding June 2015 + + +Appendix A. Encoding Examples + +A.1. Wavelength Converter Accessibility Field + + Figure 1 shows a wavelength converter pool architecture known as + "shared per fiber". In this case, the input and output pool matrices + are simply: + + +-----+ +-----+ + | 1 1 | | 1 0 | + WI =| |, WE =| | + | 1 1 | | 0 1 | + +-----+ +-----+ + + +-----------+ +------+ + | |--------------------->| | + | |--------------------->| C | + /| | |--------------------->| o | + /D+--->| |--------------------->| m | + + e+--->| | | b |=======> + ========>| M| | Optical | +-----------+ | i | Port O1 + Port I1 + u+--->| Switch | | WC Pool | | n | + \x+--->| | | +-----+ | | e | + \| | +----+->|WC #1|--+---->| r | + | | | +-----+ | +------+ + | | | | +------+ + /| | | | +-----+ | | | + /D+--->| +----+->|WC #2|--+---->| C | + + e+--->| | | +-----+ | | o | + ========>| M| | | +-----------+ | m |=======> + Port I2 + u+--->| | | b | Port O2 + \x+--->| |--------------------->| i | + \| | |--------------------->| n | + | |--------------------->| e | + | |--------------------->| r | + +-----------+ +------+ + + Figure 1: An Optical Switch Featuring a Shared Per-Fiber Wavelength + Converter Pool Architecture + + + + + + + + + + + + +Bernstein, et al. Standards Track [Page 30] + +RFC 7581 WSON Information Encoding June 2015 + + + The wavelength converters are resource blocks and the wavelength + converter pool is a resource block pool. This can be encoded as + follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved |1| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Note: I1,I2 can connect to either WC1 or WC2 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Action=0 |0| Reserved | Length = 12 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link Local Identifier = #1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link Local Identifier = #2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Action=0 |1| Reserved | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB ID = #1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB ID = #2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Note: WC1 can only connect to O1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Action=0 |1| Reserved | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link Local Identifier = #1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Action=0 |0| Reserved | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB ID = #1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Note: WC2 can only connect to O2 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Action=0 |1| Reserved | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link Local Identifier = #2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Action=0 |0| | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB ID = #2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Bernstein, et al. Standards Track [Page 31] + +RFC 7581 WSON Information Encoding June 2015 + + +A.2. Wavelength Conversion Range Field + + This example, based on Figure 1, shows how to represent the + wavelength conversion range of wavelength converters. Suppose the + wavelength range of input and output of WC1 and WC2 are {L1, L2, L3, + L4}: + + 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 + Note: WC Set + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Action=0 |1| Reserved | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | WC ID = #1 | WC ID = #2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Note: wavelength input range + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | Num Wavelengths = 4 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Grid | C.S. | Reserved | n for lowest frequency = 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Note: wavelength output range + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 2 | Num Wavelengths = 4 | Length = 8 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Grid | C.S. | Reserved | n for lowest frequency = 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +A.3. An OEO Switch with DWDM Optics + + Figure 2 shows an electronic switch fabric surrounded by DWDM optics. + In this example, the electronic fabric can handle either G.709 or + Synchronous Digital Hierarchy (SDH) signals only (2.5 or 10 Gbps). + To describe this node, the following information in Reduced Backus- + Naur Form (RBNF) form [RFC5511] is needed: + + <Node_Info> ::= <Node_ID> + + [Other GMPLS info-elements] + + [<ConnectivityMatrix>...] + + [<ResourcePool>] + + [<RBPoolState>] + + + + + + +Bernstein, et al. Standards Track [Page 32] + +RFC 7581 WSON Information Encoding June 2015 + + + In this case, there is complete port-to-port connectivity, so the + <ConnectivityMatrix> is not required. In addition, since there are + sufficient ports to handle all wavelength signals, the <RBPoolState> + element is not needed. + + Hence, the attention will be focused on the <ResourcePool> field: + + <ResourcePool> ::= <ResourceBlockInfo> + + [<RBAccessibility>...] + + [<ResourceWaveConstraints>...] + + /| +-----------+ +-------------+ +------+ + /D+--->| +--->|Tunable Laser|-->| | + + e+--->| | +-------------+ | C | + ========>| M| | | ... | o |=======> + Port I1 + u+--->| | +-------------+ | m | Port O1 + \x+--->| |--->|Tunable Laser|-->| b | + \| | Electric | +-------------+ +------+ + | Switch | + /| | | +-------------+ +------+ + /D+--->| +--->|Tunable Laser|-->| | + + e+--->| | +-------------+ | C | + ========>| M| | | ... | o |=======> + Port I2 + u+--->| | +-------------+ | m | Port O2 + \x+--->| +--->|Tunable Laser|-->| b | + \| | | +-------------+ +------+ + | | + /| | | +-------------+ +------+ + /D+--->| |--->|Tunable Laser|-->| | + + e+--->| | +-------------+ | C | + ========>| M| | | ... | o |=======> + Port I3 + u+--->| | +-------------+ | m | Port O3 + \x+--->| |--->|Tunable Laser|-->| b | + \| +-----------+ +-------------+ +------+ + + Figure 2: An Optical Switch Built around + an Electronic Switching Fabric + + The resource block information will tell us about the processing + constraints of the receivers, transmitters, and the electronic + switch. The resource availability information, although very simple, + tells us that all signals must traverse the electronic fabric (fixed + connectivity). The resource wavelength constraints are not needed + since there are no special wavelength constraints for the resources + that would not appear as port/wavelength constraints. + + + + +Bernstein, et al. Standards Track [Page 33] + +RFC 7581 WSON Information Encoding June 2015 + + + The <ResourceBlockInfo> is encoded as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Set Field | + : (only one resource block in this example with shared | + | input/output case) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |1|1|0| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Optical Interface Class List(s) | + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Client Signal Type | + : (G-PIDs for SDH and G.709) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Bit Rate Range List | + : (2.5 Gbps, 10 Gbps) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Processing Capabilities List | + : Fixed (non optional) 3R regeneration : + : : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Since there is fixed connectivity to resource blocks (the electronic + switch), the <RBAccessibility> 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Connectivity=0|Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Input Link Set Field A #1 | + : (All input links connect to resource) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RB Set Field A #1 | + : (trivial set only one resource block) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Output Link Set Field B #1 | + : (All output links connect to resource) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + +Bernstein, et al. Standards Track [Page 34] + +RFC 7581 WSON Information Encoding June 2015 + + +Contributors + + Diego Caviglia + Ericsson + Via A. Negrone 1/A 16153 + Genoa + Italy + Phone: +39 010 600 3736 + EMail: diego.caviglia@ericsson.com + + Anders Gavler + Acreo AB + Electrum 236 + SE - 164 40 Kista + Sweden + EMail: Anders.Gavler@acreo.se + + Jonas Martensson + Acreo AB + Electrum 236 + SE - 164 40 Kista + Sweden + EMail: Jonas.Martensson@acreo.se + + Itaru Nishioka + NEC Corp. + 1753 Simonumabe + Nakahara-ku, Kawasaki, Kanagawa 211-8666 + Japan + Phone: +81 44 396 3287 + EMail: i-nishioka@cb.jp.nec.com + + Pierre Peloso + ALU + EMail: pierre.peloso@alcatel-lucent.com + + Cyril Margaria + EMail: cyril.margaria@gmail.com + + Giovanni Martinelli + Cisco + EMail: giomarti@cisco.com + + Gabriele M Galimberti + Cisco + EMail: ggalimbe@cisco.com + + + + + +Bernstein, et al. Standards Track [Page 35] + +RFC 7581 WSON Information Encoding June 2015 + + + Lyndon Ong + Ciena Corporation + EMail: lyong@ciena.com + + Daniele Ceccarelli + Ericsson + EMail: daniele.ceccarelli@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bernstein, et al. Standards Track [Page 36] + +RFC 7581 WSON Information Encoding June 2015 + + +Authors' Addresses + + Greg M. Bernstein (editor) + Grotto Networking + Fremont, California + United States + Phone: (510) 573-2237 + EMail: gregb@grotto-networking.com + + + Young Lee (editor) + Huawei Technologies + 5340 Legacy Drive Build 3 + Plano, TX 75024 + United States + Phone: (469) 277-5838 + EMail: leeyoung@huawei.com + + + Dan Li + Huawei Technologies Co., Ltd. + F3-5-B R&D Center, Huawei Base, + Bantian, Longgang District + Shenzhen 518129 + China + Phone: +86-755-28973237 + EMail: danli@huawei.com + + + Wataru Imajuku + NTT Network Innovation Labs + 1-1 Hikari-no-oka, Yokosuka, Kanagawa + Japan + Phone: +81-(46) 859-4315 + EMail: imajuku.wataru@lab.ntt.co.jp + + + Jianrui Han + Huawei Technologies Co., Ltd. + F3-5-B R&D Center, Huawei Base, + Bantian, Longgang District + Shenzhen 518129 + China + Phone: +86-755-28972916 + EMail: hanjianrui@huawei.com + + + + + + +Bernstein, et al. Standards Track [Page 37] + |