One document matched: draft-martinelli-ccamp-optical-imp-signaling-03.txt
Differences from draft-martinelli-ccamp-optical-imp-signaling-02.txt
Internet Engineering Task Force G. Martinelli, Ed.
Internet-Draft Cisco Systems
Intended status: Standards Track A. Zanardi, Ed.
Expires: April 28, 2011 CREATE-NET
October 25, 2010
GMPLS Signaling Extensions for Optical Impairment Aware Lightpath Setup
draft-martinelli-ccamp-optical-imp-signaling-03.txt
Abstract
The problem of provisioning a lightpath in a transparent dense
wavelength division multiplexing (DWDM) optical island requires the
evaluation of of the optical impairments along the selected route.
In this memo we propose a GMPLS signaling protocol (RSVP/RSVP-TE)
extension to collect and provide the egress node the optical
impairment parameters needed to validate a lightpath setup request
feasibility.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 28, 2011.
Copyright Notice
Copyright (c) 2010 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
Martinelli & Zanardi Expires April 28, 2011 [Page 1]
Internet-Draft Optical Impairment Signaling October 2010
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Optical Path Impairment Validation . . . . . . . . . . . . . . 5
3.1. Procedure for Distributed Validation . . . . . . . . . . . 5
3.2. The Wavelenght Assignment Problem . . . . . . . . . . . . 6
4. Optical Parameters Classification . . . . . . . . . . . . . . 6
5. Information Encoding . . . . . . . . . . . . . . . . . . . . . 7
6. Optical Service Parameters sub-TLV . . . . . . . . . . . . . . 9
6.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 10
6.2. Modulation Format . . . . . . . . . . . . . . . . . . . . 10
7. Optical Path Parameters sub-TLV(s) . . . . . . . . . . . . . . 11
7.1. Optical Parameter sub-TLV overview . . . . . . . . . . . . 12
7.2. Mandatory Linear Optical Parameters sub-TLVs . . . . . . . 12
7.2.1. Optical Power . . . . . . . . . . . . . . . . . . . . 12
7.2.2. Optical Signal to Noise Ratio . . . . . . . . . . . . 13
7.3. Optional Linear Optical Parameters sub-TLVs . . . . . . . 13
7.3.1. Chromatic Dispersion (CD) . . . . . . . . . . . . . . 13
7.3.2. Polarization Mode Dispersion (PMD) . . . . . . . . . . 13
7.3.3. Cross-Talk (XT) . . . . . . . . . . . . . . . . . . . 13
8. Message Fragmentation . . . . . . . . . . . . . . . . . . . . 13
9. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 16
10. Error management . . . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
12. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 16
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
14. Security Considerations . . . . . . . . . . . . . . . . . . . 18
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
15.1. Normative References . . . . . . . . . . . . . . . . . . . 18
15.2. Informative References . . . . . . . . . . . . . . . . . . 19
Martinelli & Zanardi Expires April 28, 2011 [Page 2]
Internet-Draft Optical Impairment Signaling October 2010
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Martinelli & Zanardi Expires April 28, 2011 [Page 3]
Internet-Draft Optical Impairment Signaling October 2010
1. Introduction
The current Generalized Multi-Protocol Label Switching (GMPLS)
specification [RFC3945] and the signaling related documents
([RFC3471], [RFC3473], [RFC4328]) support optical interfaces with
different switching capability. Current optical switching
technologies allow implementation of Wavelength Switched Optical
Networks (WSON) and their relationship with control plane are defined
within framework [I-D.ietf-ccamp-rwa-wson-framework] and related
documents.
The implementation technology for the WSON is the Dense Wavelength
Division Multiplexing (DWDM) and, one of the key issue is the
physical impairments incurred by non-ideal optical transmission
medium that accumulate along an optical path. For a successful
lightpath provisioning in a WSON, the set up process must be aware of
a set of physical impairments that has effect on the lightpath. From
control plane perspetive the WSON probelm is divied within two main
categories: the routing and waveleght assigment problem (as the
framework above), and the impairment awareness. For this case the
framework [I-D.ietf-ccamp-wson-impairments]. provides the motivation
why optical impairments are important and details all possible.
control plane architectural options.
This memo apply to an Impairment Validation process (IV) defined
within the framework as Distributed process and it is related to the
approximated scenario ([I-D.ietf-ccamp-wson-impairments] Scenario C,
section 3.1). Proposes extensions relates to signaling protocol
(RSVP/RSVP-TE) as a way to collect and verify optical impairments for
a lightpath setup. The management of optical impairments is done
only in the signaling process and it does not require any extension
to the traffic engineering database and routing protocols or Path
Computational Element (PCE).
For what regarding signaling, WSON network require already some
specific extentions as defined within
[I-D.ietf-ccamp-wson-signaling]. This document will add some
specific information referring to the IV process.
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].
In additions this document will use terminology from [RFC2205],
[RFC3209], [RFC4054], and [I-D.ietf-ccamp-rwa-wson-framework].
Martinelli & Zanardi Expires April 28, 2011 [Page 4]
Internet-Draft Optical Impairment Signaling October 2010
3. Optical Path Impairment Validation
This section report an high level description on how the the
distributed IV process will work. From a procedural aspect it will
be compatible with both RWA and distributed wavelenght assignment
process.
3.1. Procedure for Distributed Validation
The signaling based validation of an optical path in downstream
direction in a transparent network (lambda switched LSP) is
implemented by the following procedure:
o Within Path message, the ingress node signals in supported signal
types (Forward Error Correction and modulation format) and
wavelength set (encoded in the LABEL_SET Object) depending on
available local transponders. These parameters refer to signal
compatibility within [I-D.ietf-ccamp-wson-signaling].
o Transit nodes update the Path messagecomputing or measuring the
path optical characteristics up to the outgoing interface (optical
impairments). In case of Distributed Wavelenght assignment trasit
node will pruning non cross-connectable wavelengths (LABEL_SET
Object).
o The egress node selects the wavelength and the signal type based
on the signaled optical impairments and the available local
transponders (supported wavelengths, sensitivity to optical
impairments) and signals the selection in the Resv message.
o Transit nodes process the Resv message cross-connecting the
selected wavelength in incoming and outgoing interfaces
(wavelength continuity constraint).
o The ingress node cross-connects the selected wavelength to a local
transponder supporting the selected signal type (Forward Error
Correction and modulation format).
In the Path message processing, the unavailability of cross-
connectable wavelength in transit nodes or of transponders supporting
the signal in the egress node causes the request failure (PathErr
message).
In the Resv message processing, the unavailability of the selected
wavelength in transit nodes or of transponders supporting the signal
in the ingress node (race condition in allocating resources) causes
the request failure (ResvErr message).
Martinelli & Zanardi Expires April 28, 2011 [Page 5]
Internet-Draft Optical Impairment Signaling October 2010
This procedure forces the meeting of the wavelength continuity
constraint: the final effect of pruning wavelengths (e.g. removing
labels from the LABEL_SET object) in transit nodes is the
implementation of a wavelength selection process in the signaling
phase. The wavelength assignment will be done at the egress node
among all available wavelength for the LSP. The criteria used by the
egress node to assign the wavelength is out of the scope of this
document and is reported in [I-D.ietf-ccamp-wson-signaling]
3.2. The Wavelenght Assignment Problem
The impairment framework document [I-D.ietf-ccamp-wson-impairments]
details how the Routing and Wavelength Assignment (RWA) function and
the Impairment Validation (IV) function can be combined withing
different architectural options.
The distributed IV as detailed in this memo is compatible with
different options for implementing the WA function. In case the WA
function is implemented elsewhere the procedure above still apply
apart from considering a single wavelength instead of a wavelength
set. If optical validation fail along the path, instead of pruning a
wavelet, the node will reply directly with a PathErr and the
Lightpath setup will fail.
4. Optical Parameters Classification
The set of optical parameters carried by the signaling protocol is
divided into optical service parameters and optical path parameters.
The actual list is defined elsewhere like [ITU.G680] and
[I-D.bernstein-wson-impairment-info]. Scope of this section is just
to propose a classification appropriate for RSVP-TE encoding.
o Optical Service Parameters.
For DWDM networks the egress node of an LSP has to know a certain
set of specific optical parameters related to the transmitting
interface. The optical service parameters describe the requested
signal type and are related to the characteristics of the
transponder at ingress node. They MUST NOT change at transit
nodes. Section 6 details of parameters and their encoding.
In the standard signaling, GENERALIZED_LABEL_REQUEST and TSPEC/
FLOW_SPEC objects support the encoding of equivalent information
like the service type and service QoS. In the context of WSON
also the draft [I-D.ietf-ccamp-wson-signaling] reports some of
this parameters.
Martinelli & Zanardi Expires April 28, 2011 [Page 6]
Internet-Draft Optical Impairment Signaling October 2010
o Optical Path Parameters.
The optical path parameters describe the signal characteristics
evolution along the path from ingress node to egress node, are
related to the characteristics of the various links/subsystems and
are updated at each transit node. They are divided into mandatory
and optional parameters. The mandatory parameters are related to
feasibility constraints such as power and OSNR, whereas the
optional parameters are expandable linear impairments such as
chromatic dispersion (CD), polarization mode dispersion (PMD),
crosstalk, etc. The optional parameters can be used to evaluate
the feasibility of a lightpath more accurately as an alternate
solution to the bounded OSNR margin evaluation. Parameter update
methods might use appropriate physical models and are out of scope
of this document. The [I-D.bernstein-wson-impairment-info]
identifies which are the parameters and the related ITU-T source
document. Section 7 shows RSVP-TE encoding details.
5. Information Encoding
This document defines how to encode the above information through new
TLVs according to [RFC5420].
The proposed encoding scheme for the optical parameters defines a TLV
(channel optical physical information) associated to a wavelength
containing a sub-TLV for each service and path parameter.
Additional set of parameters can be added without affecting the
already defined encoding.
A TLV sub-object for each available wavelength (Path message) or
selected wavelength (Resv message) is encoded in an
LSP_REQUIRED_ATTRIBUTES Object.
The TLV sub-object encoding is defined in the next picture.
Martinelli & Zanardi Expires April 28, 2011 [Page 7]
Internet-Draft Optical Impairment Signaling October 2010
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wavelength ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Parameters Sub-TLV Sequence //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
o Type: optical channel physical parameters info TLV type (TBA).
o Length: total length of the TLV including header in octets.
o Wavelength ID: wavelength label identifier according to
[I-D.ietf-ccamp-gmpls-g-694-lambda-labels].
o Parameters Sub-TLV Sequence: service and path parameters values.
The TLVs wavelength ID value must be consistent with the presence of
LABEL_SET objects and its actions as defined within [RFC3471] and
[RFC3473].
The Sub-TLV format is defined in the next picture
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 | Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
Type: Sub-TLV type
Flags: bit-mask defining the management of the Sub-TLV
bit 0: if set the parameter is mandatory, otherwise it is
optional.
Martinelli & Zanardi Expires April 28, 2011 [Page 8]
Internet-Draft Optical Impairment Signaling October 2010
bit 1: if set the parameter is variable and MUST be updated
with the local value, otherwise it is a constant value set by
the ingress node.
bit 2-7: not used.
Length: total length of the sub-TLV including header in octects.
Value: variable length Sub-TLV content
The Flags field defines how transit nodes manage the Sub-TLV:
o Constant sub-TLVs are forwarded as-is.
o Mandatory non constant sub-TLVs MUST be updated with the local
parameter value, if the parameter is not managed by the node, it
MUST reject the request with a failure.
o Optional non constant sub-TLVs MUST be updated with the local
parameter value, if the parameter is not managed by the node, it
MUST silently drop it from the TLV (the value would be
inaccurate).
6. Optical Service Parameters sub-TLV
The Optical Service Parameters define the signal transmissions
characteristics at the ingress node. This type of information is
required at the egress node to verify the optical signal
compatibility.
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 | Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC 1 | Mod Format 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC n | Mod Format n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
Martinelli & Zanardi Expires April 28, 2011 [Page 9]
Internet-Draft Optical Impairment Signaling October 2010
Type: sub-TLV type (=1)
Flags: Mandatory, Constant
Length: total length of the sub-TLV including header in octets
FEC: supported Forward Error Correction Modes (see Section 6.1
Mod Format: supported modulation formats (see Section 6.2)
associated with the FEC.
This sub-TLV is used in the PATH message to signal the full list of
optical parameters associated with the interface (signal types and
wavelengths) available at the ingress node. A DWDM interface might
have several sets of optical parameters available, for example a
tunable interface has a set of possible wavelengths, together with a
set of possible FEC encoding or modulation formats. In the RESV
message this information is associated to the selected receiving
interface at the egress node. In the RESV message only one tuple
(FEC, Mod Format) will be specified.
6.1. Forward Error Correction (FEC)
FEC (16 bits) field is the Forward Error Correction and has the
following values:
0: no FEC
1: standard FEC (according to [ITU.G709])
2-9: super-FEC according to sub clauses from I.2 to I.9 of
[ITU.G975.1]
Values with the format 1bbbbbbbbbbbbbbb are left to represent vendor
specific or proprietary FEC encoding.
6.2. Modulation Format
Editorial Node: this encoding section need to be reviewed with
[I-D.ietf-ccamp-wson-signaling].
Mod Format (16 bits) is the modulation and has the following values:
0: NRZ
1: Duo Binary
Martinelli & Zanardi Expires April 28, 2011 [Page 10]
Internet-Draft Optical Impairment Signaling October 2010
2: DPSK
Other values might be defined in the future as technology advance.
Values with the format 1bbbbbbbbbbbbbbb are left to represent vendor
specific or proprietary modulation formats.
7. Optical Path Parameters sub-TLV(s)
This set of parameters is carried in the PATH message for each
available wavelength to allow the optical feasibility evaluation. At
each hop, the optical node MUST update these values according to
information locally available at the node (say internal amplifiers,
wavelength cross connect, etc.). This sub-TLV implements the
Distributed Impairment evaluation as per
[I-D.bernstein-wson-impairment-info]
The way an optical node gets knowledge of this required information
(e.g. through network management system, auto-discovery etc.) is out
of the scope of this document and highly depends on specific
equipment implementation.
This document defines two groups of linear optical parameters.
Mandatory Linear Optical Parameters
This set includes Optical Signal Power and the OSNR with
associated variances. It represents the minimum set to asses the
feasibility of an optical path. This set will be encoded using
mandatory sub-TLVs.
Optional Linear Optical Parameters
This set includes CD, PMD, XT with associated variances. These
parameters represent an additional set to allow a more accurate
optical feasibility evaluation. This set will be encoded using
optional sub-TLVs.
Separation between mandatory and optional parameters allows a rough
optical feasibility evaluation where network elements support at
least the mandatory set. Depending on how a WSON is designed, the
usage of the mandatory set could be an operational choice not to
overwhelm the control plane while maintaining reliable feasibility
estimation. Moreover it might happens that not all nodes in a
networks support the full set of optical path parameters. With this
classification, the lightpath signaling still continues to work
although with a less accurate evaluation.
The choice of the optional set of parameters depends on several
considerations. They are among those reported by the [RFC4054] and
Martinelli & Zanardi Expires April 28, 2011 [Page 11]
Internet-Draft Optical Impairment Signaling October 2010
provide sufficient accuracy for the linear impairments evaluation.
7.1. Optical Parameter sub-TLV overview
Each optical parameter will be encoded using 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 | Flags | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Parameter Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optical Parameter Variance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
Type: sub_TLV type > 1.
Flags: mandatory or optional according to each parameter
classification, variable.
Length: total length of the Sub-TLV including header in octets (8
octets or 12 octets depending if the optical parameter has the
variance value associated).
Value associated with the optical parameter.
Variance: the error estimation for optical parameter value
calculation. Depending on the length value may not be present.
7.2. Mandatory Linear Optical Parameters sub-TLVs
The Sub-TLVs encode the following optical parameters of a channel
(wavelength) measured at the node egress interface. Flags are:
mandatory, variable.
7.2.1. Optical Power
Type = 2.
Value: 32bit IEEE floating point number. Measurement Unit: dBm.
Martinelli & Zanardi Expires April 28, 2011 [Page 12]
Internet-Draft Optical Impairment Signaling October 2010
7.2.2. Optical Signal to Noise Ratio
Type = 3.
Value: 32bit IEEE floating point number. Measurement Unit: dB.
7.3. Optional Linear Optical Parameters sub-TLVs
The Sub-TLVs encode the following optical parameters of a channel
(wavelength) measured at the node egress interface. Flags are:
optional, variable.
7.3.1. Chromatic Dispersion (CD)
Type = 4.
Value: 32bit IEEE floating point number. Measurement Unit: ps/nm.
7.3.2. Polarization Mode Dispersion (PMD)
Type = 5.
Value: 32bit IEEE floating point number. Measurement Unit: ps.
7.3.3. Cross-Talk (XT)
Type = 6.
Value: 32bit IEEE floating point number. Measurement Unit: dB.
8. Message Fragmentation
In certain cases, the state information carried by the Path message
can be quite large. Size estimation for a physical Optical Channel
TLV (see Figure 1) can be the following: 8 bytes for type, length and
wavelength ID plus, 16 bytes for the Optical Service Parameters sub-
TLV considering 3 FEC/modulation format combinations plus, 24 bytes
for the Mandatory Linear Optical Path parameters plus 36 bytes for
the Optional Linear Optical Parameter sub-TLV. Total is 48 bytes for
each wavelength by just considering mandatory sub-TLVs and 84 bytes
by considering also the optional part. Given the number of
wavelengths today available in DWDM networks, the size of the path
message end up in large values. For example to signal just 32
wavelengths the size required for the physical optical parameters
ranges at least from 1536 to 2688 bytes.
A possible option is to let the application layer requesting the
Martinelli & Zanardi Expires April 28, 2011 [Page 13]
Internet-Draft Optical Impairment Signaling October 2010
lightpath setup to decide how many wavelengths to signal according to
the MTU available. For example, having an MTU of 1500 bytes the
application layer might signal only 10 wavelengths with the full set
of parameters taking up 840 bytes, or it might decide to signal 20
wavelengths with just the mandatory parameters. Note that, according
to procedure described within Section 3, the message size may
decrease as long as the Path message pass through transit nodes.
A second solution proposed here implements the semantic fragmentation
as suggested by RSVP [RFC2205]. The proposed encoding extends the
SENDER_TEMPLATE Object with a new Class Type (derived from the
LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 RSVP-TE [RFC3209]). The Object
includes the additional information on the "fragment id" and on the
requested policy for the channel selection at the egress node
Class = SENDER_TEMPLATE, FRAGREQ_LSP_TUNNEL_IPv4 C-Type = TBA
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TotalNo | MsgId | P | Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
Martinelli & Zanardi Expires April 28, 2011 [Page 14]
Internet-Draft Optical Impairment Signaling October 2010
Class = SENDER_TEMPLATE, FRAGREQ_LSP_TUNNEL_IPv6 C-Type = TBA
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TotalNo | MsgId | P | Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
Besides the fields already defined in the SENDER_TEMPLATE, the
following fields are defined:
o TotalNo: 8 bit integer representing the total number of Path
messages issued by the ingress node to setup a single lightpath.
When this values is equals to 1 all the other fields MUST be
ignored.
o MsgId: 8 bit integer representing the sequential number of a
single Path request. Its value must be between 1 and TotalNo,
both inclusive.
o P: Policy the egress node must apply upon receiving a fragmented
path request:
1: Take the first message arrived and ignore the
following ones.
2: After the first message arrives, wait for any message
within the specified Timeout.
3: After the first message arrives, waits for all
messages. Fail, if the timeout expires, and there's at
least one message missing
The egress node should "reject" (PathErr) all the requests except
for the selected one, even if it could rely on the RSVP timeout
to clear the unselected requests status in upstream nodes.
Martinelli & Zanardi Expires April 28, 2011 [Page 15]
Internet-Draft Optical Impairment Signaling October 2010
o Timeout: 12 bits integer number representing the timeout value
used by the policy. The value is in s/100 (hundreds of seconds)
All messages MUST have the same value.
This type of encoding is a generic solution to manage the semantic
fragmentation and its not strictly related to optical parameters
encoding.
9. Backward Compatibility
The TLV usage as defined by [RFC5420] will guarantee the co-existence
of nodes supporting normal RSVP-TE operations and node with optical
impairment signaling capability.
A service with the new feature (optical feasibility evaluation) can
be setup only if all the nodes in the path support the extensions.
Optical Path Parameters are updated hop-by-hop and evaluated at
egress node. If a transit node does not support the extensions the
collected information is unreliable and the Path request MUST be
rejected.
10. Error management
No additional error code is introduced to manage requests failures;
the behavior defined in [RFC5420] applies to the management of the
LSP_REQUIRED_ATTRIBUTES Object.
11. Acknowledgments
12. Contributing Authors
This document was the collective work of several authors. The text
and content of this document was contributed by the editors and the
co-authors listed below (the contact information for the editors
appears in appropriate section and is not repeated below):
Martinelli & Zanardi Expires April 28, 2011 [Page 16]
Internet-Draft Optical Impairment Signaling October 2010
Gabriele Maria Galimberti
Cisco Systems
via Philips 12
Monza 20052, Italy
Email: ggalimbe@cisco.com
Alberto Tanzi
Cisco Systems
via Philips 12
Monza 20052, Italy
Email: atanzi@cisco.com
Domenico La Fauci
Cisco Systems
via Philips 12
Monza 20052, Italy
Email: dlafauci@cisco.com
Elio Salvadori
CREATE-NET
via alla Cascata 56 C, Povo
Trento 38100, Italy
Email: elio.salvadori@create-net.org
Chava Vijaya Saradhi
CREATE-NET
via alla Cascata 56 C, Povo
Trento 38100, Italy
Email: saradhi.chava@create-net.org
13. IANA Considerations
This memo needs the following request to IANA
TLV (see Figure 1 in Section 5)
New class type for sender template (see Section 8)
All drafts are required to have an IANA considerations section (see
the update of RFC 2434 [RFC5266] for a guide). If the draft does not
require IANA to do anything, the section contains an explicit
Martinelli & Zanardi Expires April 28, 2011 [Page 17]
Internet-Draft Optical Impairment Signaling October 2010
statement that this is the case (as above). If there are no
requirements for IANA, the section will be removed during conversion
into an RFC by the RFC Editor.
14. Security Considerations
This document introduces no new security considerations to [RFC3473].
GMPLS security is described in section 11 of [RFC3471] and refers to
[RFC3209] for RSVP-TE.
15. References
15.1. Normative References
[ITU.G680]
International Telecommunications Union, "Physical transfer
functions of optical network elements", ITU-
T Recommendation G.680, July 2007.
[ITU.G709]
International Telecommunications Union, "Interface for the
Optical Transport Network (OTN)", ITU-T Recommendation
G.709, March 2003.
[ITU.G975.1]
International Telecommunications Union, "Forward Error
Correction for high bit rate DWDM Submarine Systems", ITU-
T Recommendation G.975, February 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Martinelli & Zanardi Expires April 28, 2011 [Page 18]
Internet-Draft Optical Impairment Signaling October 2010
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, January 2006.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009.
15.2. Informative References
[I-D.bernstein-wson-impairment-info]
Lee, Y., Bernstein, G., Systems, C., Martinelli, G., and
A. Zanardi, "Information Model for Impaired Optical Path
Validation", draft-bernstein-wson-impairment-info-03 (work
in progress), October 2010.
[I-D.ietf-ccamp-gmpls-g-694-lambda-labels]
Otani, T., Rabbat, R., Shiba, S., Guo, H., Miyazaki, K.,
Caviglia, D., Li, D., and T. Tsuritani, "Generalized
Labels for Lambda-Switching Capable Label Switching
Routers", draft-ietf-ccamp-gmpls-g-694-lambda-labels-07
(work in progress), April 2010.
[I-D.ietf-ccamp-rwa-wson-framework]
Bernstein, G., Lee, Y., and W. Imajuku, "Framework for
GMPLS and PCE Control of Wavelength Switched Optical
Networks (WSON)", draft-ietf-ccamp-rwa-wson-framework-07
(work in progress), October 2010.
[I-D.ietf-ccamp-wson-impairments]
Bernstein, G., Lee, Y., Li, D., Martinelli, G., Chen, M.,
Han, J., Galimberti, G., Tanzi, A., Bianchi, D., Kattan,
M., Schroetter, D., Ceccarelli, D., Bellagamba, E., and D.
Caviglia, "A Framework for the Control of Wavelength
Switched Optical Networks (WSON) with Impairments",
draft-ietf-ccamp-wson-impairments-04 (work in progress),
October 2010.
[I-D.ietf-ccamp-wson-signaling]
Bernstein, G., Andriolli, N., Giorgetti, A., Guo, L.,
Harai, H., Ji, Y., King, D., Lee, Y., and S. Xu,
"Signaling Extensions for Wavelength Switched Optical
Networks", draft-ietf-ccamp-wson-signaling-00 (work in
progress), October 2010.
Martinelli & Zanardi Expires April 28, 2011 [Page 19]
Internet-Draft Optical Impairment Signaling October 2010
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC4054] Strand, J. and A. Chiu, "Impairments and Other Constraints
on Optical Layer Routing", RFC 4054, May 2005.
[RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and
Mobility Using Mobile IPv4 and IKEv2 Mobility and
Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008.
Authors' Addresses
Giovanni Martinelli (editor)
Cisco Systems
via Philips 12
Monza 20052
Italy
Email: giomarti@cisco.com
Andrea Zanardi (editor)
CREATE-NET
via alla Cascata 56 C, Povo
Trento 38100
Italy
Email: andrea.zanardi@create-net.org
Martinelli & Zanardi Expires April 28, 2011 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-24 01:58:20 |