draft-ietf-ccamp-wson-signaling-04.txt   draft-ietf-ccamp-wson-signaling-05.txt 
Network Working Group G. Bernstein Network Working Group G. Bernstein
Internet Draft Grotto Networking Internet Draft Grotto Networking
Intended status: Standards Track Sugang Xu Intended status: Standards Track Sugang Xu
NICT NICT
Expires: April 2013 Y.Lee Expires: August 2013 Y.Lee
Huawei Huawei
G. Martinelli G. Martinelli
Cisco Cisco
Hiroaki Harai Hiroaki Harai
NICT NICT
October 22, 2012 February 18, 2013
Signaling Extensions for Wavelength Switched Optical Networks Signaling Extensions for Wavelength Switched Optical Networks
draft-ietf-ccamp-wson-signaling-04.txt draft-ietf-ccamp-wson-signaling-05.txt
Abstract Abstract
This memo provides extensions to Generalized Multi-Protocol Label This memo provides extensions to Generalized Multi-Protocol Label
Switching (GMPLS) signaling for control of wavelength switched Switching (GMPLS) signaling for control of wavelength switched
optical networks (WSON). Such extensions are necessary in WSONs optical networks (WSON). Such extensions are necessary in WSONs
under a number of conditions including: (a) when optional under a number of conditions including: (a) when optional
processing, such as regeneration, must be configured to occur at processing, such as regeneration, must be configured to occur at
specific nodes along a path, (b) where equipment must be configured specific nodes along a path, (b) where equipment must be configured
to accept an optical signal with specific attributes, or (c) where to accept an optical signal with specific attributes, or (c) where
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 22, 2007. This Internet-Draft will expire on August 18, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 2, line 38 skipping to change at page 2, line 38
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Terminology....................................................3 2. Terminology....................................................3
3. Requirements for WSON Signaling................................4 3. Requirements for WSON Signaling................................4
3.1. WSON Signal Characterization..............................4 3.1. WSON Signal Characterization..............................4
3.2. Per LSP Network Element Processing Configuration..........5 3.2. Per LSP Network Element Processing Configuration..........5
3.3. Bi-Directional WSON LSPs..................................5 3.3. Bi-Directional WSON LSPs..................................5
3.4. Distributed Wavelength Assignment Support.................6 3.4. Distributed Wavelength Assignment Selection Method........6
3.5. Out of Scope..............................................6 3.5. Out of Scope..............................................6
4. WSON Signal Traffic Parameters, Attributes and Processing......6 4. WSON Signal Traffic Parameters, Attributes and Processing......6
4.1. Traffic Parameters for Optical Tributary Signals..........6 4.1. Traffic Parameters for Optical Tributary Signals..........7
4.2. Signal Attributes and Processing..........................7 4.2. Signal Attributes and Processing Capabilities.............7
4.2.1. WSON Processing Object Encoding......................8 4.3. Wavelength Assignment Method Selection....................8
5. Bidirectional Lightpath Setup..................................8 4.4. WSON Processing Object Encoding...........................9
6. RWA Related....................................................9 5. Bidirectional Lightpath Setup.................................10
6.1. Wavelength Assignment Method Selection....................9 6. Security Considerations.......................................10
7. Security Considerations.......................................10 7. IANA Considerations...........................................11
8. IANA Considerations...........................................10 8. Acknowledgments...............................................11
9. Acknowledgments...............................................10 9. References....................................................12
10. References...................................................11 9.1. Normative References.....................................12
10.1. Normative References....................................11 9.2. Informative References...................................13
10.2. Informative References..................................11 Author's Addresses...............................................15
Author's Addresses...............................................14 Intellectual Property Statement..................................16
Intellectual Property Statement..................................15 Disclaimer of Validity...........................................17
Disclaimer of Validity...........................................16
1. Introduction 1. Introduction
This memo provides extensions to Generalized Multi-Protocol Label This memo provides extensions to Generalized Multi-Protocol Label
Switching (GMPLS) signaling for control of wavelength switched Switching (GMPLS) signaling for control of wavelength switched
optical networks (WSON). Fundamental extensions are given to permit optical networks (WSON). Fundamental extensions are given to permit
simultaneous bi-directional wavelength assignment while more simultaneous bi-directional wavelength assignment while more
advanced extensions are given to support the networks described in advanced extensions are given to support the networks described in
[RFC6163] which feature connections requiring configuration of [RFC6163] which feature connections requiring configuration of
input, output, and general signal processing capabilities at a node input, output, and general signal processing capabilities at a node
skipping to change at page 6, line 14 skipping to change at page 6, line 14
(a) Where the same wavelength is used for both upstream and (a) Where the same wavelength is used for both upstream and
downstream directions downstream directions
(b) Where different wavelengths can be used for both upstream and (b) Where different wavelengths can be used for both upstream and
downstream directions. downstream directions.
This document will review current GMPLS bidirectional solutions This document will review current GMPLS bidirectional solutions
according to WSON case. according to WSON case.
3.4. Distributed Wavelength Assignment Support 3.4. Distributed Wavelength Assignment Selection Method
WSON signaling MAY support the selection of a specific distributed WSON signaling MAY support the selection of a specific distributed
wavelength assignment method. wavelength assignment method.
This method is beneficial in cases of equipment failure, etc., where This method is beneficial in cases of equipment failure, etc., where
fast provisioning used in quick recovery is critical to protect fast provisioning used in quick recovery is critical to protect
carriers/users against system loss. This requires efficient carriers/users against system loss. This requires efficient
signaling which supports distributed wavelength assignment, in signaling which supports distributed wavelength assignment, in
particular when the centralized wavelength assignment capability is particular when the centralized wavelength assignment capability is
not available. not available.
skipping to change at page 7, line 4 skipping to change at page 7, line 9
classes characterized by modulation format and bit rate. Although classes characterized by modulation format and bit rate. Although
WSONs are fairly transparent to the signals they carry, to ensure WSONs are fairly transparent to the signals they carry, to ensure
compatibility amongst various networks devices and end systems it compatibility amongst various networks devices and end systems it
can be important to include key lightpath characteristics as traffic can be important to include key lightpath characteristics as traffic
parameters in signaling [RFC6163]. parameters in signaling [RFC6163].
4.1. Traffic Parameters for Optical Tributary Signals 4.1. Traffic Parameters for Optical Tributary Signals
In [RFC3471] we see that the G-PID (client signal type) and bit rate In [RFC3471] we see that the G-PID (client signal type) and bit rate
(byte rate) of the signals are defined as parameters and in (byte rate) of the signals are defined as parameters and in
[RFC3473] they are conveyed Generalized Label Request object and the [RFC3473] they are conveyed Generalized Label Request object and the
RSVP SENDER_TSPEC/FLOWSPEC objects respectively. RSVP SENDER_TSPEC/FLOWSPEC objects respectively.
4.2. Signal Attributes and Processing 4.2. Signal Attributes and Processing Capabilities
Section 3.2. gave the requirements for signaling to indicate to a The [WSON-Encode] already provides all necessary definitions and
particular NE along an LSP what type of processing to perform on an encoding for WSON information required for signaling. In particular,
optical signal or how to configure that NE to accept or transmit an the Resource block information sub-TLV contains, among others, a
optical signal with particular attributes. list of available Optical Interface Classes and processing
capabilities.
One way of accomplishing this is via a new EXPLICIT_ROUTE subobject. <RBInformation> is defined in Section 5.1 of [WSON-Encode].
Reference [RFC3209] defines the EXPLICIT_ROUTE object (ERO) and a
number of subobjects, while reference [RFC5420] defines general
mechanisms for dealing with additional LSP attributes. Although
reference [RFC5420] defines a RECORD_ROUTE object (RRO) attributes
subobject, it does not define an ERO subobject for LSP attributes.
Regardless of the exact coding for the ERO subobject conveying the Type Sub-TLV
input, output, or processing instructions. This new "processing"
subobject would follow a subobject containing the IP address, or the
interface identifier [RFC3477], associated with the link on which it
is to be used along with any label subobjects [RFC3473].
In regards to specific information required, the [WSON-Encode] 1 (TBA) <RBInformation>
already provides all necessary definitions and encoding. In
particular the Resource block information sub-TLV which contains,
among others, a list of available Optical Interface Classes and
processing capabilities.
The WSON Signal Processing object is defined as an LSP_ATTRIBUTES One <RBInformation> sub-TLV MUST always be present in the
and extends the PATH message. It is defined as the following: WSON_SIGNALING object;otherwise, a PathErr shall be generated. At
most two <RBInformation> sub-TLVs MAY be present in the
WSON_SIGNALING object. If more than two objects are encountered, two
MUST be processed and the rest SHOULD be ignored.
<WSON Processing> ::= <RBInformation> The <RBInformation> contains several information. The following
processing rules apply:
RB Set Field MAY contain more than one RB Indetifier. Only the first
one MUST be processed, the others SHOULD be ignored.
The Optical Interface Class List, Input Bit Range List and
Processing Capability List MAY contain more than one element. Only
the first MUST be processed, the others SHOULD be ignored.
4.3. Wavelength Assignment Method Selection
Routing + Distributed wavelength assignment (R+DWA) is one of the
options defined by the [RFC6163]. The output from the routing
function will be a path but the wavelength will be selected on a
hop-by-hop basis.
Under this hypothesis the node initiating the signaling process
needs to declare its own wavelength availability (through a
label_set object). Each intermediate node may delete some labels due
to connectivity constraints or its own assignment policy. At the
end, the destination node has to make the final decision on the
wavelength assignment among the ones received through the signaling
process.
As discussed in [HZang00] a number of different wavelength
assignment algorithms maybe employed. In addition as discussed in
[RFC6163] the wavelength assignment can be either for a
unidirectional lightpath or for a bidirectional lightpath
constrained to use the same lambda in both directions.
A simple sub-TLV could be used to indication wavelength assignment
directionality and wavelength assignment method.
Type Sub-TLV
2 <WavelengthSelection>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|W| WA Method | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where: Where:
<RBInformation> is the object defined in Section 5.1 of [WSON- W is a bit, 0 same wavelength in both directions, 1 may use
Encode]. different wavelengths
Wavelength Assignment Method: 0 unspecified (any), 1 First-Fit,
2 Random, 3 Least-Loaded (multi-fiber). Others TBD.
This is the only sub-TLV available within the <WSON Processing>. This sub-TLV MAY be present in the WSON_SIGNALING object. If more
Only one <RBInformation> object MUST be present. than one sub-TLV is encountered the first one MUST be processed, the
rest SHOULD be ignored.
4.2.1. WSON Processing Object Encoding 4.4. WSON Processing Object Encoding
Section 3.2. provided the requirements for signaling to indicate to
a particular NE along an LSP what type of processing to perform on
an optical signal or how to configure that NE to accept or transmit
an optical signal with particular attributes.
To target a specific node, this section defines a WSON_SIGNALING
object as part of the LSP_REQUIRED_ATTRIBUTE and follows procedures
defined in [RSVP-RO].
The content of this object is defined in the previous sections 4.2
and 4.3:
<WSON_SIGNALING> ::= <RBInformation> [<RBInformation>]
[<WavelengthSelection>]
The WSON_SIGNALING object encoding is defined as:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Value ~ ~ Value ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: to be defined by IANA Type: to be defined by IANA
Value: sub-TLVS according to section 4.1. Value: sub-TLVS according to section 4.2 and 4.3
5. Bidirectional Lightpath Setup 5. Bidirectional Lightpath Setup
With the wavelength continuity constraint in CI-incapable [RFC3471] With the wavelength continuity constraint in CI-incapable [RFC3471]
WSONs, where the nodes in the networks cannot support wavelength WSONs, where the nodes in the networks cannot support wavelength
conversion, the same wavelength on each link along a unidirectional conversion, the same wavelength on each link along a unidirectional
lightpath should be reserved. In addition to the wavelength lightpath should be reserved. In addition to the wavelength
continuity constraint, requirement 3.3 gives us another constraint continuity constraint, requirement 3.3 gives us another constraint
on wavelength usage in data plane, in particular, it requires the on wavelength usage in data plane, in particular, it requires the
same wavelength to be used in both directions. [RFC6163] in section same wavelength to be used in both directions. [RFC6163] in section
skipping to change at page 9, line 12 skipping to change at page 10, line 39
regeneration, the same information applies to both downstream and regeneration, the same information applies to both downstream and
upstream directions. upstream directions.
Some implementations may prefer using two unidirectional LSPs. This Some implementations may prefer using two unidirectional LSPs. This
solution has been always available as per [RFC3209] however recent solution has been always available as per [RFC3209] however recent
work introduces the association concept [RFC4872] and [ASSOC-Info]. work introduces the association concept [RFC4872] and [ASSOC-Info].
Recent transport evolutions [ASSOC-ext] provide a way to associate Recent transport evolutions [ASSOC-ext] provide a way to associate
two unidirectional LSPs as a bidirectional LSP. In line with this, a two unidirectional LSPs as a bidirectional LSP. In line with this, a
small extension can make this approach work for the WSON case. small extension can make this approach work for the WSON case.
6. RWA Related 6. Security Considerations
6.1. Wavelength Assignment Method Selection
Routing + Distributed wavelength assignment (R+DWA) is one of the
options defined by the [RFC6163]. The output from the routing
function will be a path but the wavelength will be selected on a
hop-by-hop basis.
Under this hypothesis the node initiating the signaling process
needs to declare its own wavelength availability (through a
label_set object). Each intermediate node may delete some labels due
to connectivity constraints or its own assignment policy. At the
end, the destination node has to make the final decision on the
wavelength assignment among the ones received through the signaling
process.
As discussed in [HZang00] a number of different wavelength
assignment algorithms maybe employed. In addition as discussed in
[RFC6163] the wavelength assignment can be either for a
unidirectional lightpath or for a bidirectional lightpath
constrained to use the same lambda in both directions.
A simple TLV could be used to indication wavelength assignment
directionality and wavelength assignment method. This would be
placed in an LSP_REQUIRED_ATTRIBUTES object per [RFC5420]. The use
of a TLV in the LSP required attributes object was pointed out in
[Xu].
[TO DO: The directionality stuff needs to be reconciled with the
earlier material]
Unique Wavelength: 0 same wavelength in both directions, 1 may use
different wavelengths [TBD: shall we use only 1 bit]
Wavelength Assignment Method: 0 unspecified (any), 1 First-Fit, 2
Random, 3 Least-Loaded (multi-fiber). Others TBD.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique WL | WA Method | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7. Security Considerations
This document has no requirement for a change to the security models This document has no requirement for a change to the security models
within GMPLS and associated protocols. That is the OSPF-TE, RSVP-TE, within GMPLS and associated protocols. That is the OSPF-TE, RSVP-TE,
and PCEP security models could be operated unchanged. and PCEP security models could be operated unchanged.
However satisfying the requirements for RWA using the existing However satisfying the requirements for RWA using the existing
protocols may significantly affect the loading of those protocols. protocols may significantly affect the loading of those protocols.
This makes the operation of the network more vulnerable to denial of This makes the operation of the network more vulnerable to denial of
service attacks. Therefore additional care maybe required to ensure service attacks. Therefore additional care maybe required to ensure
that the protocols are secure in the WSON environment. that the protocols are secure in the WSON environment.
Furthermore the additional information distributed in order to Furthermore the additional information distributed in order to
address the RWA problem represents a disclosure of network address the RWA problem represents a disclosure of network
capabilities that an operator may wish to keep private. capabilities that an operator may wish to keep private.
Consideration should be given to securing this information. Consideration should be given to securing this information.
8. IANA Considerations 7. IANA Considerations
TBD. Once finalized in our approach we will need identifiers for A new LSP_REQUIRED_ATTRIBUTE type is required
such things and modulation types, modulation parameters, wavelength
assignment methods, etc...
9. Acknowledgments TBA: WSON Object (Section 4.4)
Two types of sub-TLV are allowed within the WSON object
Value Sub-TLV
1 (Proposed) WSON Processing Capabilities (Section 4.2)
2 (Proposed) WSON Wavelength Assignments (Section 4.3)
8. Acknowledgments
Authors would like to thanks Lou Berger and Cyril Margaria for Authors would like to thanks Lou Berger and Cyril Margaria for
comments and suggestions. comments and suggestions.
10. References 9. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)", "Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999. STD 58, RFC 2578, April 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
skipping to change at page 11, line 43 skipping to change at page 12, line 43
[RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A. [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A.
Ayyangar, " Encoding of Attributes for MPLS LSP Ayyangar, " Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2006. Engineering (RSVP-TE)", RFC 5420, February 2006.
[WSON-Encode] Bernstein G., Lee Y., Li D., and W. Imajuku, "Routing [WSON-Encode] Bernstein G., Lee Y., Li D., and W. Imajuku, "Routing
and Wavelength Assignment Information Encoding for and Wavelength Assignment Information Encoding for
Wavelength Switched Optical Networks", draft-ietf-ccamp- Wavelength Switched Optical Networks", draft-ietf-ccamp-
rwa-wson-encode-18 (work in progress), September 2012. rwa-wson-encode-18 (work in progress), September 2012.
10.2. Informative References [RSVP-RO] Margaria, C., et al, "LSP Attribute in ERO", draft-ietf-
ccamp-lsp-attribute-ro (work in progress), Febrauary 2013.
9.2. Informative References
[WSON-CompOSPF] Y. Lee, G. Bernstein, "OSPF Enhancement for Signal [WSON-CompOSPF] Y. Lee, G. Bernstein, "OSPF Enhancement for Signal
and Network Element Compatibility for Wavelength Switched and Network Element Compatibility for Wavelength Switched
Optical Networks", work in progress: draft-lee-ccamp-wson- Optical Networks", work in progress: draft-lee-ccamp-wson-
signal-compatibility-OSPF. signal-compatibility-OSPF.
[RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS
and PCE Control of Wavelength Switched Optical Networks", and PCE Control of Wavelength Switched Optical Networks",
work in progress: draft-bernstein-ccamp-wavelength- work in progress: draft-bernstein-ccamp-wavelength-
switched-03.txt, February 2008. switched-03.txt, February 2008.
 End of changes. 27 change blocks. 
105 lines changed or deleted 124 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/