draft-ietf-ccamp-wson-signaling-03.txt   draft-ietf-ccamp-wson-signaling-04.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: September 2012 Y.Lee Expires: April 2013 Y.Lee
Huawei Huawei
G. Martinelli G. Martinelli
Cisco Cisco
Hiroaki Harai Hiroaki Harai
NICT NICT
March 7, 2012 October 22, 2012
Signaling Extensions for Wavelength Switched Optical Networks Signaling Extensions for Wavelength Switched Optical Networks
draft-ietf-ccamp-wson-signaling-03.txt draft-ietf-ccamp-wson-signaling-04.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 September 7, 2012. This Internet-Draft will expire on April 22, 2007.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 3, line 4 skipping to change at page 3, line 4
3.4. Distributed Wavelength Assignment Support.................6 3.4. Distributed Wavelength Assignment Support.................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..........6
4.2. Signal Attributes and Processing..........................7 4.2. Signal Attributes and Processing..........................7
4.2.1. WSON Processing Object Encoding......................8 4.2.1. WSON Processing Object Encoding......................8
5. Bidirectional Lightpath Setup..................................8 5. Bidirectional Lightpath Setup..................................8
6. RWA Related....................................................9 6. RWA Related....................................................9
6.1. Wavelength Assignment Method Selection....................9 6.1. Wavelength Assignment Method Selection....................9
7. Security Considerations.......................................10 7. Security Considerations.......................................10
8. IANA Considerations...........................................11 8. IANA Considerations...........................................10
9. Acknowledgments...............................................11 9. Acknowledgments...............................................10
10. References...................................................12 10. References...................................................11
10.1. Normative References....................................12 10.1. Normative References....................................11
10.2. Informative References..................................12 10.2. Informative References..................................11
Author's Addresses...............................................14 Author's Addresses...............................................14
Intellectual Property Statement..................................15 Intellectual Property Statement..................................15
Disclaimer of Validity...........................................16 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
along a LSP along a LSP.
These extensions build on previous work for the control of lambda These extensions build on previous work for the control of lambda
and G.709 based networks. and G.709 based networks.
2. Terminology 2. Terminology
CWDM: Coarse Wavelength Division Multiplexing. CWDM: Coarse Wavelength Division Multiplexing.
DWDM: Dense Wavelength Division Multiplexing. DWDM: Dense Wavelength Division Multiplexing.
skipping to change at page 5, line 16 skipping to change at page 5, line 16
1. Optical tributary signal class (modulation format). 1. Optical tributary signal class (modulation format).
2. FEC: whether forward error correction is used in the digital 2. FEC: whether forward error correction is used in the digital
stream and what type of error correcting code is used stream and what type of error correcting code is used
3. Center frequency (wavelength) 3. Center frequency (wavelength)
4. Bit rate 4. Bit rate
5. G-PID: General Protocol Identifier for the information format 5. G-PID: General Protocol Identifier for the information format
The first three items on this list can change as a WSON signal The first three items on this list can change as a WSON signal
traverses a network with regenerators, OEO switches, or wavelength traverses a network with regenerators, OEO switches, or wavelength
converters. An ability to control wavelength conversion already converters. These parameters are summarized in the Optical Interface
exists in GMPLS signaling along with the ability to share client Class as defined in the [WSON-Info] and the assumption is that a
signal type information (G-PID). In addition, bit rate is a standard class always includes signal compatibility information.
GMPLS signaling traffic parameter. It is referred to as Bandwidth An ability to control wavelength conversion already exists in GMPLS
Encoding in [RFC3471]. This leaves two new parameters: modulation signaling along with the ability to share client signal type
format and FEC type, needed to fully characterize the optical information (G-PID). In addition, bit rate is a standard GMPLS
signal. signaling traffic parameter. It is referred to as Bandwidth Encoding
in [RFC3471].
3.2. Per LSP Network Element Processing Configuration 3.2. Per LSP Network Element Processing Configuration
In addition to configuring a network element (NE) along an LSP to In addition to configuring a network element (NE) along an LSP to
input or output a signal with specific attributes, we may need to input or output a signal with specific attributes, we may need to
signal the NE to perform specific processing, such as 3R signal the NE to perform specific processing, such as 3R
regeneration, on the signal at a particular NE. In [RFC6163] we regeneration, on the signal at a particular NE. In [RFC6163] we
discussed three types of processing not currently covered by GMPLS: discussed three types of processing not currently covered by GMPLS:
(A) Regeneration (possibly different types) (A) Regeneration (possibly different types)
skipping to change at page 6, line 11 skipping to change at page 6, line 11
WSON signaling MAY support LSP setup consistent with the wavelength WSON signaling MAY support LSP setup consistent with the wavelength
continuity constraint for bi-directional connections. The following continuity constraint for bi-directional connections. The following
cases MAY be separately supported: cases MAY be separately supported:
(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.
(Editor's Note: an evaluation of current GMPLS bidirectional This document will review current GMPLS bidirectional solutions
solutions should be evaluated if they would fit to the current WSON according to WSON case.
needs.)
3.4. Distributed Wavelength Assignment Support 3.4. Distributed Wavelength Assignment Support
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
skipping to change at page 7, line 28 skipping to change at page 7, line 28
mechanisms for dealing with additional LSP attributes. Although mechanisms for dealing with additional LSP attributes. Although
reference [RFC5420] defines a RECORD_ROUTE object (RRO) attributes reference [RFC5420] defines a RECORD_ROUTE object (RRO) attributes
subobject, it does not define an ERO subobject for LSP attributes. subobject, it does not define an ERO subobject for LSP attributes.
Regardless of the exact coding for the ERO subobject conveying the Regardless of the exact coding for the ERO subobject conveying the
input, output, or processing instructions. This new "processing" input, output, or processing instructions. This new "processing"
subobject would follow a subobject containing the IP address, or the subobject would follow a subobject containing the IP address, or the
interface identifier [RFC3477], associated with the link on which it interface identifier [RFC3477], associated with the link on which it
is to be used along with any label subobjects [RFC3473]. is to be used along with any label subobjects [RFC3473].
In regards to specific information required, the [WSON-Encode]
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 The WSON Signal Processing object is defined as an LSP_ATTRIBUTES
and extends the PATH message. It is defined as the following: and extends the PATH message. It is defined as the following:
<WSON Processing> ::= <hop information> <Transmitter Capabilities> <WSON Processing> ::= <RBInformation>
<Receiver Capabilities> [<RegenerationCapabilities>]
<Receiver Capabilities> ::= <ModulationTypeList> <FECTypeList>
<BitRateRange>
<Transmitter Capabilities> ::=
(ModulationTypeList> <FECTypeList> <BitRateRange>
Where: Where:
<hop information>: Ipv4,Ipv6 address. Note: this not required if <RBInformation> is the object defined in Section 5.1 of [WSON-
WSON Processing object become part of the ERO Encode].
<Transmitter Capabilities> is defined in [WSON-Encode].
<ReceiverCapabilities> is defined in [WSON-Encode].
<ModulationTypeList> is defined in[WSON-Encode]
<FECTypeList> is defined in [WSON-Encode]
<BitRateRange> is defined in [WSON-Encode]
<RegenerationCapabilities> is defined in [WSON-Encode]
<RegenerationCapabilities> are only applied in the intermediate This is the only sub-TLV available within the <WSON Processing>.
nodes of the LSP. The head and tail nodes will ignore regeneration Only one <RBInformation> object MUST be present.
capability processing.
4.2.1. WSON Processing Object Encoding 4.2.1. WSON Processing Object Encoding
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 ~
skipping to change at page 9, line 4 skipping to change at page 8, line 27
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.1.
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.2 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
6.1 reports on the implication to GMPLS signaling related to both 6.1 reports on the implication to GMPLS signaling related to both
bi-directionality and Distributed Wavelengths Assignment. bi-directionality and Distributed Wavelengths Assignment.
Current GMPLS solution defines a bidirectional LSP (as defined by Current GMPLS solution defines a bidirectional LSP (as defined by
[RFC3471]). The label distribution is based on Label_Set and [RFC3471]). The label distribution is based on Label_Set and
Upstream_Label objects. In case of specific constraints such as the Upstream_Label objects. In case of specific constraints such as the
same wavelengths in both directions, it may require several same wavelengths in both directions, it may require several
signaling attempts using information from the Acceptable_Label_Set signaling attempts using information from the Acceptable_Label_Set
received from path error messages. received from path error messages. Since this mechanism is currently
available and proven to work, no additional extensions are needed
for WSON. Potential optimizations are left for further studies.
The usage of <WSON Processing> object for the bidirectional case is
the same as per unidirectional. When an intermediate node uses
information from this object to instruct a node about wavelength
regeneration, the same information applies to both downstream and
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. RWA Related
skipping to change at page 11, line 13 skipping to change at page 10, line 38
Consideration should be given to securing this information. Consideration should be given to securing this information.
8. IANA Considerations 8. IANA Considerations
TBD. Once finalized in our approach we will need identifiers for TBD. Once finalized in our approach we will need identifiers for
such things and modulation types, modulation parameters, wavelength such things and modulation types, modulation parameters, wavelength
assignment methods, etc... assignment methods, etc...
9. Acknowledgments 9. Acknowledgments
Anyone who provide comments and helpful inputs Authors would like to thanks Lou Berger and Cyril Margaria for
comments and suggestions.
10. References 10. References
10.1. Normative References 10.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)",
skipping to change at page 12, line 38 skipping to change at page 11, line 38
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, January 2003.
[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
and Wavelength Assignment Information Encoding for
Wavelength Switched Optical Networks", draft-ietf-ccamp-
rwa-wson-encode-18 (work in progress), September 2012.
10.2. Informative References 10.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.
[WSON-Info] G. Bernstein, Y. Lee, D. Li, W. Imajuku, "Routing and
Wavelength Assignment Information Model for Wavelength
Switched Optical Networks", work in progress: draft-ietf-
ccamp-rwa-info-16, September 2012.
[HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing
and wavelength assignment approaches for wavelength-routed and wavelength assignment approaches for wavelength-routed
optical WDM networks", Optical Networks Magazine, January optical WDM networks", Optical Networks Magazine, January
2000. 2000.
[Xu] S. Xu, H. Harai, and D. King, "Extensions to GMPLS RSVP-TE [Xu] S. Xu, H. Harai, and D. King, "Extensions to GMPLS RSVP-TE
for Bidirectional Lightpath the Same Wavelength", work in for Bidirectional Lightpath the Same Wavelength", work in
progress: draft-xu-rsvpte-bidir-wave-01, November 2007. progress: draft-xu-rsvpte-bidir-wave-01, November 2007.
[Winzer06] Peter J. Winzer and Rene-Jean Essiambre, "Advanced [Winzer06] Peter J. Winzer and Rene-Jean Essiambre, "Advanced
 End of changes. 17 change blocks. 
49 lines changed or deleted 53 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/