Network Working Group G. BernsteinInternetDraftEngineering Task Force (IETF) G. Bernstein, Ed. Request for Comments: 7581 Grotto NetworkingIntended status:Category: Standards Track Y.Lee Expires: August 2015Lee, Ed. ISSN: 2070-1721 D. Li Huawei W. Imajuku NTTFebruary 24,J. Han Huawei June 2015 Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networksdraft-ietf-ccamp-rwa-wson-encode-28.txtAbstract Awavelength switched optical networkWavelength Switched Optical Network (WSON) requiresthatcertain key information fieldsarebe made available to facilitate path computation and the establishment oflabel switching pathsLabel 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. Inadditionaddition, these encodings could be used by other mechanisms to convey this same information to apath computation elementPath Computation Element (PCE). Status ofthisThis Memo ThisInternet-Draftissubmitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force(IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum(IETF). It represents the consensus ofsix monthsthe IETF community. It has received public review andmay be updated, replaced, or obsoletedhas been approved for publication byother documents at any time. Itthe Internet Engineering Steering Group (IESG). Further information on Internet Standards isinappropriate to use Internet-Drafts as reference material or to cite them other than as "workavailable inprogress." The listSection 2 of RFC 5741. Information about the currentInternet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The liststatus ofInternet-Draft Shadow Directories canthis document, any errata, and how to provide feedback on it may beaccessedobtained athttp://www.ietf.org/shadow.html This Internet-Draft will expire on August 24, 2015.http://www.rfc-editor.org/info/rfc7581. Copyright Notice Copyright (c)20142015 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.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].Table of Contents 1.Introduction...................................................3Introduction ....................................................4 1.1.Terminology..................................................4Terminology ................................................4 1.2. Conventions Used in This Document ..........................5 2. Resources, Resource Blocks, and the ResourcePool..............4Pool ...............5 2.1. Resource Block SetField..................................5Field ...................................5 3. ResourceAccessibility/Availability............................6Accessibility/Availability .............................7 3.1. Resource AccessibilityField..............................6Field ...............................7 3.2. Resource Wavelength ConstraintsField.....................8Field ......................9 3.3. Resource Block Pool State(RBPoolState) Field.............9Field ...........................10 3.4. Resource Block Shared Access Wavelength Availability(RBSharedAccessWaveAvailability) Field........................11Field ........................................12 4. Resource Block Information(ResourceBlockInfo) Field..........12Field ...............................13 4.1. Optical Interface Class ListSubfield....................14Subfield .....................15 4.1.1.ITU-G.698.1ITU-T G.698.1 Application CodeMapping.............16Mapping .............17 4.1.2.ITU-G.698.2ITU-T G.698.2 Application CodeMapping.............18Mapping .............18 4.1.3.ITU-G.959.1ITU-T G.959.1 Application CodeMapping.............19 ITU-G.695Mapping .............20 4.1.4. ITU-T G.695 Application CodeMapping.....................22 4.1.4...................................................22Mapping ...............22 4.2. Acceptable Client Signal ListSubfield................24Subfield ....................23 4.3. Input Bit Rate ListSubfield..........................24Subfield ..............................24 4.4. Processing Capability ListSubfield...................25Subfield .......................24 5. SecurityConsiderations.......................................27Considerations ........................................26 6. IANAConsiderations...........................................27Considerations ............................................26 6.1. Types forsubfieldsSubfields of WSON Resource BlockInformation...27Information ....26 7.Acknowledgments...............................................28 APPENDIX A:References .....................................................27 7.1. Normative References ......................................27 7.2. Informative References ....................................28 Appendix A. EncodingExamples....................................29Examples .....................................30 A.1. Wavelength Converter AccessibilityField.................29Field ..................30 A.2. Wavelength Conversion RangeField........................31Field .........................32 A.3. An OEO Switch with DWDMOptics...........................31 8. References....................................................35 8.1. Normative References.....................................35 8.2. Informative References...................................35 9. Contributors..................................................37Optics ............................32 Contributors ......................................................35 Authors'Addresses...............................................38Addresses ................................................37 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,[RWA-Info][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 theroutingRouting andwavelength assignmentWavelength Assignment (RWA) process in a WSON. Such encodings can be used to extend GMPLS signaling and routing protocols. Inadditionaddition, these encodings could be used by other mechanisms to convey this same information to apath computation element (PCE).PCE. Note that since these encodings areefficientefficient, they can provide more accurate analysis of thecontrol planecontrol-plane communications/processing load for WSONs looking to utilize a GMPLS control plane. In parallel to this document,[Gen-Encode][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] forCWDM, DWDM, RWA, WDM. Refer to Section 5definitions of[RWA-Info] fortheterminology of Resources, Resource Blocks, and Resource Pool. 2. Resources, Resource Blocks,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 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[RWA-Info][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 PCEprotocolCommunication Protocol (PCEP) [RFC5440]. Note that the information distributed in [RFC4203] and [RFC5307] is arranged via the nesting of sub-TLVs withinTLVs andTLVs; this document defines elements to be used within such constructs. Specific constructs of sub-TLVs and the nesting of sub-TLVs of the informationfieldfields 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 thefollowingfielddefinition.definition in Section 2.1. 2.1. Resource Block Set Field In a WSON node that includes resource blocks(RB),(RBs), denoting subsets of these blocks allows one to efficiently describe common properties of the blocks and to describe the structure and characteristics, ifnon-trivial,nontrivial, of the resource pool. TheRBResource Block Setfield(RB Set) Field is defined in a similar manner to the label set concept of [RFC3471]. The information carried in an RBset fieldSet Field is definedby: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 RBidentifier.identifiers. The first 32 bits is the RB identifier for the start of therangerange, 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 (Connectivitybit):bit) Set to 0 to denote fixed (possiblymulti- cast) connectivity; Setmulticast) connectivity, and set to 1 to denote potential (switched) connectivity. Used in Resource Accessibility field. Ignored elsewhere. 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 resourceblockblock, which is a32 bit32-bit integer. The scope of the RB identifier is local to the node on which it is applied. Usage Note:theThe inclusive range "Action" can result in very compact encoding of resourcesetssets, 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 theResourceAccessibility, ResourceWaveConstraints,<ResourceAccessibility>, <ResourceWaveConstraints>, <RBPoolState>, andRBPoolState<RBSharedAccessWaveAvailability> fields. 3.1. Resource Accessibility Field This information field describes the structure of the resource pool in relation to the switching device. Inparticularparticular, 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 thePoolInputMatrix<PoolInputMatrix> andPoolOutputMatrix<PoolOutputMatrix> of[RWA-Info].[RFC7446]. The Resource Accessibility field is definedby: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 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+WhereWhere: 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[Gen-Encode][RFC7579] is to be used.A Label Set Field MUST carry a label as defined in [RFC6205].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. 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 opticalsystemsystem, not all wavelengths can necessarily reach or leave all the resources. These properties are described by using one or moreresource wavelength restrictionsResource 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 ConstraintsField and I =field 0 - indicates otherwise. O=(Output): 1 - indicates the presence of the Output Wavelength ConstraintsField and O =field 0 - indicates otherwise. B=(Both): 1 - indicates that a singlewavelength constraintsWavelength Constraints field represents both Input and Output Wavelength ConstraintsFields. Currentlyfields. Currently, the only valid combinations of (I,O,B) are (1,0,0), (0,1,0), (1,1,0), and (0,0,1). RB Set Field: A set of resource blocks (RBs)whichthat have the same wavelength restrictions. Input WavelengthConstraints Field:Constraints: Indicates the wavelength input restrictions of the RBs in the corresponding RB set. This field is encoded via the Label SetfieldField of[Gen-Encode].[RFC7579]. Output WavelengthConstraints Field:Constraints: Indicates the wavelength output restrictions of RBs in the corresponding RB set. This field is encoded via the Label SetfieldField of[Gen-Encode].[RFC7579]. 3.3. Resource Block Pool State(RBPoolState)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 of16 bit16-bit integer values or abit mapbitmap indicating whether a single resource is available or in use. Thebit mapbitmap 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(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 UsagestateState | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+WhereWhere: Action = 0 denotes a list of16 bit integers16-bit integers, and Action = 1 denotes abit map.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. In bothcasescases, the elements of the RB SetfieldField are in a one-to-one correspondence with the values in theusageRBusage stateUsage 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#1stateState | RB#2stateState | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RB#n-1stateState | RB#nstateState or Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RB#i State (16 bits, unsigned integer):indicatesIndicates 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 RBset field.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 Usagestate bitmapState Bitmap | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | PaddingbitsBits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RB Usagestate:State Bitmap: VariableLengthlength but must be a multiple of 4byes.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 thebit mapbitmap is ordered according to the RB SetfieldField with this element. Padding bits: VariableLengthlength 3.4. Resource Block Shared Access Wavelength Availability(RBSharedAccessWaveAvailability)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): 1or 0- indicates the presenceor absenceof the Input Available Wavelength SetField O = 1 orField. 0 - indicates the absence of the Input Available Wavelength Set Field. O (Output): 1 - indicates the presenceorof 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.CurrentlyCurrently, the only valid combinations of (I,O,B) are (1,0,0), (0,1,0), (1,1,0), and (0,0,1). RB Set Field: AResource Blockresource 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 SetfieldField of[Gen-Encode].[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 SetfieldField of[Gen-Encode].[RFC7579]. 4. Resource Block Information(ResourceBlockInfo)Field As defined in[RWA-Info],[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:(a)o Optical Interface Class List(s)(b)o Acceptable Client Signal (shared input, modulation,FEC,Forward Error Correction (FEC), bit rate,G-PID) (c)and Generalized Protocol Identifier (G-PID)) o Input Bit Rate(d)o Processing Capabilities (number of resources in a block, regeneration, performance monitoring, vendor specific)ResourceBlockInfo<ResourceBlockInfo> fields are used to convey relatively static information about individual resourceblocksblocks, including the resource block properties and the number of resources in a block. When more than oneResourceBlockInfo<ResourceBlockInfo> field is used, there are no ordering requirements amongst these fields. The length of theResourceBlockInfo<ResourceBlockInfo> field is determined from the length of the object that includes it.This ResourceBlockInfoThe <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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionalsubfieldSubfield 1 | : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OptionalsubfieldSubfield 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)(O), and the third bit(B):(B). I=(Input): 1 - indicates if the resource blocks identified in the RBset fieldSet Field utilized a shared fiber for inputaccess and and I =access. 0 - indicates otherwise. O=(Output): 1 - indicates if the resource blocks identified in the RBset fieldSet Field utilized a shared fiber for outputaccess and O =access. 0 - indicates otherwise. B=(Both): 1 - indicates if the resource blocks identified in the RBset fieldSet Field utilized a shared fiber for both input and outputaccess and B =access. 0 - indicates otherwise.CurrentlyCurrently, 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 OptionalsubfieldsSubfields MAY be present. OptionalsubfieldsSubfields 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(thus, a subfield with no value portion would have a length of zero). The subfield is padded tofour-byte4-byte alignment; padding is not included in the Length field (so athree byte3-byte value would have a length of three, but the total size of the subfield would beeight byte).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 followingsubfield Typessub-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 newTypes.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 | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. TheResource Blockresource 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: SStandard bit. S=0, identify(Standard bit): S=0: identifies non-ITU code pointsS=1, identifyS=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-specificAIapplication codes once the ITU-T has completed its work in that area. With S=1, the OI Code Points field can take the following values: 0: reserved 1: [G.698.1] applicationcode.code 2: [G.698.2] applicationcode.code 3: [G.959.1] applicationcode.code 4: [G.695] applicationcode.code In the case of ITUApplication Codes,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-G.698.1ITU-T G.698.1 Application Code Mapping[698.1][G.698.1] defines theApplication Codes:following application codes: DScW-ytz(v) andB-DScW- ytz(v).B-DScW-ytz(v). Where: B: meansBidirectional.Bidirectional D: means a DWDMapplication.application S: takes values N (narrow spectralexcursion),excursion) or W (wide spectralexcursion).excursion) c: Channel Spacing(GHz).(GHz) W: takes values S(short-haul),(short-haul) or L(long-haul).(long-haul) y: takes values 1 (NRZ2.5G),2.5G) or 2(indicating NRZ 10G).(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(indicating [G.655] fibre).([G.655] fibre) v: takes values S (Short wavelength), C (Conventional), or L (Longwavelength).wavelength) The F flag indicates the presence or absence of an optional FECEncodingencoding suffix. These get mapped into the64 bit OIC64-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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wherevalues(values between parentheses refer toITU definedITU-defined values as reportedabove: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 inFigure 2the third figure in Section 3.2 of [RFC6205] (note that DWDM spacing applieshere)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 FECEncodingencoding suffix present,=1 FECEncodingencoding 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-G.698.2ITU-T G.698.2 Application Code Mapping [G.698.2] defines theApplication Codes:following application codes: DScW-ytz(v) andB-DScW- ytz(v).B-DScW-ytz(v). Where: B: meansBidirectional.Bidirectional D: means a DWDMapplication.application S: takes values N (narrow spectralexcursion),excursion) or W (wide spectralexcursion).excursion) c: Channel Spacing(GHz).(GHz) W: takes values C (link is dispersioncompensated),compensated) or U (link is dispersionuncompensated).uncompensated) y: takes values 1 (NRZ2.5G),2.5G) or 2(indicating NRZ 10G).(NRZ 10G) t: takes value A (link may contains optical amplifier) z: takes values 2 ([G.652] fibre), 3 ([G.653] fibre), or 5(indicating [G.655] fibre).([G.655] fibre) v: takes values S (Short wavelength), C (Conventional), or L (Longwavelength).wavelength) AnOptionaloptional F can be addedindicatingto indicate a FECEncoding.encoding. These get mapped into the 64-bitOICOptical 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 toITU definedITU-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 inFigure 2the third figure in Section 3.2 of [RFC6205] (note that DWDM spacing applieshere)here). W:=0 reserved,=10 (C),=11 (U) y:=0 reserved,=1 (1),=2 (2) 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 FECEncodingencoding Values not mentioned here are not allowed in this applicationcode, thecode. The last 32 bits are reserved and shall be set to zero. 4.1.3.ITU-G.959.1ITU-T G.959.1 Application Code Mapping [G.959.1] defines theApplication Codes: PnWx-ytz andfollowing application codes: PnWx-ytz and BnWx-ytz. Where: P,B: whenpresentpresent, 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 (ultralong-haul).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 (RZ40G).40G) t: takes values A (power levels suitable for a booster amplifier in the originating ONE and power levels suitable for apre-amplifierpre- amplifier in the terminating ONE), B (booster amplifier only), C(pre- amplifier(pre-amplifier only), or D (noamplifiers).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: FECencoding.encoding D: Adaptive dispersioncompensation.compensation E: receiver capable of dispersioncompensation.compensation r: reduced targetdistance.distance a: power levels appropriate to APDreceivers.receivers b: power levels appropriate to PINreceivers.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 toITU definedITU-defined values as reported above): p(prefix) =(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 issuffix: a 6-bitbitmap: 0 1 2 3 4 5 +-+-+-+-+-+-+ |F|D|E|r|a|b| +-+-+-+-+-+-+bitmap, where a1"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| +-+-+-+-+-+-+ 4.1.4.ITU-G.695ITU-T G.695 Application Code Mapping [G.695] defines theApplication Codes: CnWx-ytz and B-CnWx-ytzfollowing 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),(short-haul) or L(long-haul).(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).fibre) The following list of suffixes can be added to these application codes: F: FECencoding.encoding Since the application codes are very similar to the ones from the[G.959] section[G.959.1] section, most of the fields are reused. The 64-bitOICOptical 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where (values between parentheses refer toITU definedITU-defined values as reported above): p:=0 no prefix,=1B(B) bidirectional,=2S(S) black link C:=0 reserved,=3(C).(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),=22 (2), > 2 reserved t:=4 (D), all other values are reserved z:=0 reserved,=1 (1),=2 (2),=3 (3)suffix issuffix: a 6-bitbitmap: 0 1 2 3 4 5 +-+-+-+-+-+-+ |F|0|0|0|0|0| +-+-+-+-+-+-+bitmap, where a1"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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type (16 bits): identifies the Acceptable Client Signal List field. Length (16 bits): The Length field defines the length of the value portion in octets. The numberNumber ofG-PIDs isG-PIDs: an integer greater than or equal to one.G-PIDs areG-PIDs: assigned byIANA and manyIANA. 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 Theprocessing capability list fieldProcessing 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 specificVendor-specific capability Fault and performance monitoring andVendor specificvendor-specific capability have no additional capability parameters. Theprocessing capability list fieldProcessing Capability List subfield isthen given by: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 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Theprocessing capabilityProcessing Cap ID field defines the following processing capabilities: 0: Reserved 1: Regeneration capability 2: Fault and performance monitoring 3:Vendor specificVendor-specific capability When theprocessingProcessing Cap ID is"regeneration"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 RegeneratorWhereAnd 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 beSelective"Selective RegenerationPools,Pools", regeneration pool properties such as input and output restrictions and availability need to be specified. These properties will be encoded in thecapabilitiesfield providing additional capability parameters, starting with the bits marked Reserved in thefigure.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 registrywill behas been created to make the assignment of a new type and new values for the new "GMPLS Routing Parameters forWSON".WSON" registry. Note that this registry is only used in routing, not in signaling. 6.1. Types forsubfieldsSubfields of WSON Resource Block Information Underthisthe newGMPLS"GMPLS Routing Parameters forWSON,WSON" registry, a new IANAregistry will besubregistry has been created for nested subfields of the Resource Block Information field to create a new section named "Types forsubfieldsSubfields of WSON Resource Block Information Registry".The newThis registry will be maintained via Standards Action as defined by [RFC5226].There areThe initial values in thenewregistry are as follows: Value LengthSub-TLV TypeDescription Reference ----- ------ ------------ --------- 0 Reserved 1 variable Optical Interface Class List[This.I-D][RFC7581] 2 variable Acceptable Client Signal List[This.I-D][RFC7581] 3 variable Input Bit Rate List[This.I-D][RFC7581] 4 variable Processing Capability List[This.I-D][RFC7581] 5-65535 Unassigned 7.Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. APPENDIX A: Encoding Examples A.1. Wavelength Converter Accessibility Field Example: Figure 1 shows a wavelength converter pool architecture known as "shared per fiber". In this case the input and output pool matrices are simply: +-----+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>. 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>. [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>. 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 | +-----------+ +------+ Figure11: Anoptical switch featuringOptical Switch Featuring ashared per fiber wavelength converter pool architecture.Shared Per-Fiber Wavelength Converter Pool Architecture 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A.2. Wavelength Conversion Range FieldExample:This example, based onfigureFigure 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 thisexampleexample, the electronic fabric can handle either G.709 orSDHSynchronous Digital Hierarchy (SDH) signals only (2.5 or 10 Gbps). To describe this node, the following information inRBNFReduced Backus- Naur Form (RBNF) form [RFC5511] is needed: <Node_Info> ::= <Node_ID> [Other GMPLS info-elements] [<ConnectivityMatrix>...] [<ResourcePool>] [<RBPoolState>] In thiscasecase, there is complete port-to-portconnectivityconnectivity, so the <ConnectivityMatrix> is not required. Inadditionaddition, since there are sufficient ports to handle all wavelengthsignalssignals, the <RBPoolState> element is not needed.HenceHence, 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. <ResourceBlockInfo>: 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 |m |input/output case)Port O2 \x+--->| +--->|Tunable Laser|-->| b |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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+-------------+ +------+ /D+--->| |--->|Tunable Laser|-->| |: (2.5Gbps, 10Gbps) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ e+--->| |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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+C |Connectivity=0|Reserved========>| M| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Input Link Set Field A #1... |: (All input links connect to resource) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+o |=======> Port I3 + u+--->| |RB Set Field A #1+-------------+ |: (trivial set only one resource block) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+m |Output Link Set Field B #1Port O3 \x+--->| |--->|Tunable Laser|-->| b |: (All output links connect to resource) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006. [Gen-Encode] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "General Network Element Constraint Encoding for GMPLS Controlled Networks", work in progress: draft-ietf-ccamp-general- constraint-encode. [RWA-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and Wavelength Assignment Information Model for Wavelength Switched\| +-----------+ +-------------+ +------+ Figure 2: An OpticalNetworks", work in progress: draft-ietf- ccamp-rwa-info. [RFC6205] T. Otani, H. Guo, K. Miyazaki, D. Caviglia, "Generalized Labels for G.694 Lambda-Switching Capable LabelSwitch Built around an Electronic SwitchingRouters", RFC 6205, March 2011. 8.2. Informative References [IEEE] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", Standard 754-1985, 1985 (ISBN 1-5593-7653-8). [G.652] ITU-T Recommendation G.652, Characteristics of a single-mode optical fibre and cable, September, 2011. [G.653] ITU-T Recommendation G.653, Characteristics of a dispersion- shifted, single-mode optical fibre and cable, July, 2010. [G.655] ITU-T Recommendation G.655, CharacteristicsFabric The resource block information will tell us about the processing constraints ofa non-zero dispersion-shifted single-mode optical fibrethe receivers, transmitters, andcable, September, 2011. [G.698.1] ITU-T Recommendation G.698.1, Spectral grids for WDM applications: DWDM frequency grid, June 2002. [G.698.2] ITU-T Recommendation G.698.2, Spectral grids for WDM applications: CWDMthe electronic switch. The resource availability information, although very simple, tells us that all signals must traverse the electronic fabric (fixed connectivity). The resource wavelengthgrid, December 2003. [G.695] ITU-T Recommendation G.695, Optical interfaces for coarseconstraints are not needed since there are no special wavelengthdivision multiplexing applications, October, 2010. [G.959.1] ITU-T Recommendation G.959.1, Optical transport network physical layer interfaces, February, 2012. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC4203] Kompella, L. and Y. Rekhter, Eds., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC5226] Narten, T., Alvestrand, H., "Guidelinesconstraints forWriting an IANA Considerations Section in RFCs", RFC 5226, May 2008. [RFC5307] Kompella, L. and Y. Rekhter, Eds., "IS-IS Extensionsthe resources that would not appear as port/wavelength constraints. 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 inSupport of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October, 2008. [RFC5440] Vasseur, JP.this example with shared | | input/output case) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|1|0| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optical Interface Class List(s) | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Input Client Signal Type | : (G-PIDs for SDH andLe Roux, JL., Eds., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC5511] A. Farrel, "Routing Backus-Naur Form (RBNF):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 ASyntax Used#1 | : (All input links connect toForm Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks", RFC 6163, April 2011. 9.resource) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RB Set Field A #1 | : (trivial set only one resource block) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Output Link Set Field B #1 | : (All output links connect to resource) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Contributors Diego Caviglia Ericsson Via A. Negrone 1/A 16153 Genoa Italy Phone: +39 010 600 3736Email:EMail: diego.caviglia@ericsson.com Anders Gavler Acreo AB Electrum 236 SE - 164 40 Kista SwedenEmail:EMail: Anders.Gavler@acreo.se Jonas Martensson Acreo AB Electrum 236 SE - 164 40Kista,Kista SwedenEmail:EMail: Jonas.Martensson@acreo.se Itaru Nishioka NEC Corp. 1753Simonumabe,Simonumabe Nakahara-ku, Kawasaki, Kanagawa 211-8666 Japan Phone: +81 44 396 3287Email:EMail: i-nishioka@cb.jp.nec.com Pierre Peloso ALUEmail:EMail: pierre.peloso@alcatel-lucent.com Cyril MargariaEmail:EMail: cyril.margaria@gmail.com Giovanni Martinelli CiscoEmail:EMail: giomarti@cisco.com Gabriele M Galimberti CiscoEmail:EMail: ggalimbe@cisco.com Lyndon Ong Ciena CorporationEmail:EMail: lyong@ciena.com Daniele Ceccarelli EricssonEmail:EMail: daniele.ceccarelli@ericsson.com Authors' Addresses Greg M. Bernstein(ed.)(editor) Grotto NetworkingFremont California, USAFremont, California United States Phone: (510) 573-2237Email:EMail: gregb@grotto-networking.com Young Lee(ed.)(editor) Huawei Technologies 5340 Legacy Drive Build 3 Plano, TX 75024USAUnited States Phone: (469) 277-5838Email:EMail: leeyoung@huawei.com Dan Li Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129P.R.ChinaChina Phone: +86-755-28973237Email:EMail: danli@huawei.com Wataru Imajuku NTT Network Innovation Labs 1-1 Hikari-no-oka, Yokosuka, Kanagawa Japan Phone: +81-(46) 859-4315Email: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 518129P.R.ChinaChina Phone: +86-755-28972916Email:EMail: hanjianrui@huawei.com