One document matched: draft-martinelli-ccamp-optical-imp-signaling-00.txt
Internet Engineering Task Force G. Martinelli, Ed.
Internet-Draft Cisco Systems
Intended status: Standards Track A. Zanardi, Ed.
Expires: May 11, 2008 CREATE-NET
November 8, 2007
GMPLS Signaling Extensions for Optical Impairment Aware Lightpath Setup
draft-martinelli-ccamp-optical-imp-signaling-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents 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 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 11, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The problem of provisioning a light-path in a transparent dense
wavelength division multiplexing (DWDM) optical island requires the
transmission of optical impairment related parameters along the
selected route. In this draft we propose the GMPLS signaling
protocol (RSVP/RSVP-TE) extensions to transmit optical impairments to
setup an optically feasible light-path.
Martinelli & Zanardi Expires May 11, 2008 [Page 1]
Internet-Draft Optical Impairment Signaling November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Optical Path Validation Procedure . . . . . . . . . . . . . . 4
4. Physical Parameter Classification and top level TLV . . . . . 5
5. Optical Service Parameters sub-TLV . . . . . . . . . . . . . . 7
5.1. Forward Error Correction (FEC) . . . . . . . . . . . . . . 8
5.2. Modulation Format . . . . . . . . . . . . . . . . . . . . 8
6. Optical Path Parameters sub-TLV(s) . . . . . . . . . . . . . . 8
6.1. Mandatory Linear Optical Parameters . . . . . . . . . . . 9
6.2. Optional Linear Optical Parameters . . . . . . . . . . . . 10
7. Message Fragmentation . . . . . . . . . . . . . . . . . . . . 11
8. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 14
9. Error management . . . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. Security Considerations . . . . . . . . . . . . . . . . . . . 16
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
14.1. Normative References . . . . . . . . . . . . . . . . . . . 16
14.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Martinelli & Zanardi Expires May 11, 2008 [Page 2]
Internet-Draft Optical Impairment Signaling November 2007
1. Introduction
The current Generalized Multi-Protocol Label Switching (GMPLS)
specification [RFC3945] and the signalling related documents
([RFC3471], [RFC3473], [RFC4328]) support optical interfaces with
different switching capability to setup a light-path while [RFC4054]
defines routing optical constrains on routing.
[I-D.bernstein-ccamp-wavelength-switched], defines a framework for
identifying key components and issues pertaining to wavelength
switched optical networks (WSON).
[I-D.otani-ccamp-gmpls-lambda-labels] propose a global semantic for
wavelength generalized labels taking into account light-path specific
needs.
In transparent optical networks, physical impairments incurred by
non-ideal optical transmission medium accumulate along an optical
path. Because of these impairments even if two nodes are connected
through an optical path, there is no guarantee that the optical
signal (light) reaches the end node with acceptable signal quality,
for example in terms of BER/OSNR/Q-factor limit. For a successful
light-path provisioning in a WSON, the set up process must be aware
of a set of physical impairments that has effect on the light-path.
A complete set of physical impairments will include linear and non-
linear impairments. This preliminary draft proposes a way to collect
the optical path linear impairments in the signaling phase by
providing suitable extensions to signaling protocol (RSVP/RSVP-TE)
assuming that non-linear impairments effects are handled in the
network design phase considering a bounded OSNR margin [RFC4054].
The management of physical impairments is done only in the signalling
process and it does not require any extension to the traffic
engineering database.
The set of parameters carried by the signaling protocol is divided
into optical service parameters and optical path parameters:
o The optical service parameters describe the requested signal type,
are related to the characteristics of the transponder at source
node and hence are not changed at transit nodes.
o The optical path parameters describe the signal characteristics
evolution along the path from source node to destination 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 extendable linear impairments such as
chromatic dispersion (CD), polarization mode dispersion (PMD),
Martinelli & Zanardi Expires May 11, 2008 [Page 3]
Internet-Draft Optical Impairment Signaling November 2007
crosstalk, etc. The optional parameters can be used to evaluate
the feasibility of a light-path 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.
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.bernstein-ccamp-wavelength-switched].
3. Optical Path Validation Procedure
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 The source node signals in the Path message the supported signal
types (FEC and modulation format) and wavelength set (encoded in
the LABEL_SET Object) depending on available local transponders.
o Transit nodes update the Path message pruning non cross-
connectable wavelengths (LABEL_SET Object) and computing or
measuring the path optical characteristics up to the outgoing
interface (optical impairments).
o Destination 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 Intermediate nodes process the Resv message cross-connecting the
selected wavelength in incoming and outgoing ports (wavelength
continuity constraint).
o The source node cross-connects the selected wavelength to a local
transponder supporting the selected signal type (FEC and
modulation format).
The unavailability of cross-connectable wavelength in intermediate
nodes or of transponders supporting the signal in the destination
node causes the request failure (PathErr message).
Martinelli & Zanardi Expires May 11, 2008 [Page 4]
Internet-Draft Optical Impairment Signaling November 2007
The unavailability of the selected wavelength in intermediate nodes
or of transponders supporting the signal in the source node (race
condition in allocating resources) causes the request failure
(ResvErr message).
In this document, only the encoding in the RSVP messages of the
optical information needed to support the described procedure is
defined. The specific policies used to select the resources
(wavelength and transponders), the models to compute the optical
impairments and the procedure to validate the signal with respect to
the transponder sensitivity are not in the scope of this document.
4. Physical Parameter Classification and top level TLV
The extensions required to RSVP/RSVP-TE to make them aware of optical
impairments and to setup optically feasible light-paths requires the
following information:
o Optical Service Parameters.
The standard GENERALIZED_LABEL_REQUEST and TSPEC/FLOW_SPEC objects
support the encoding of the information related to service type
and service QoS. However for DWDM networks the end node of an LSP
has to know a certain set of specific optical parameters related
to transmitting interface. Section 5 reports details of these
parameters and their encoding.
o Optical Path Parameters.
These attributes are required to support transmission of physical
impairment parameters required for the optical path feasibility
evaluation. Details are presented in Section 6.
This document defines how to encode the above information through new
TLVs according to [RFC4420].
The proposed encoding scheme for the optical parameters defines a TLV
(channel optical physical information) associated to a wavelength and
a set of sub-TLV for each set of service and path parameters.
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 May 11, 2008 [Page 5]
Internet-Draft Optical Impairment Signaling November 2007
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
Type: optical channel physical parameters info TLV type (TBA).
Length: length of the TLV object in bytes without the 4 byte header.
Wavelength ID: wavelength label identifier according to
[I-D.otani-ccamp-gmpls-lambda-labels].
Parameters Sub-TLV Sequence: service and path parameters values.
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: Mandatory if set, Optional if unset
bit 1: ToUpdate if set, Constant if unset
bit 2-7: to be assigned
Martinelli & Zanardi Expires May 11, 2008 [Page 6]
Internet-Draft Optical Impairment Signaling November 2007
Length: Value field length in bytes
Value: variable length Sub-TLV content
The Flags field defines how intermediate nodes manage unrecognized
Sub-TLV:
Unrecognized Constant sub-TLVs are forwarded as-is
Unrecognized Mandatory and ToUpdate sub-TLVs cause the reject with
a failure of the request
Unrecognized Optional and ToUpdate sub-TLVs are silently dropped
from the TLV (the value would be inaccurate)
5. Optical Service Parameters sub-TLV
The Optical Service Parameters defines the signal transmissions
characteristics at the source node. This type of information is
required at the destination 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
Type: sub-TLV type (=1)
Flags: Mandatory, Constant
Length: length of the sub-TLV value in bytes
FEC: supported Forward Error Correction Modes (see Section 5.1
Mod Format: supported modulation formats (see Section 5.2)
associated with the FEC.
Martinelli & Zanardi Expires May 11, 2008 [Page 7]
Internet-Draft Optical Impairment Signaling November 2007
This sub-TLV is used in the PATH message to signal the full list of
optical parameters associated with physical interfaces (signal types
and wavelengths) available at the source node. In the RESV message
this information is associated to the selected receiving interface at
the destination node. In the RESV message only one tuple (FEC, Mod
Format) will be specified.
5.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 of the format 1bbb.bbbb.bbbb.bbbb are left to represent vendor
specific or proprietary FEC encoding.
5.2. Modulation Format
Mod Format (16 bits) is the available modulation format at the source
node. Currently the field takes the following values:
0: NRZ
1: Duo Binary
2: DPSK
Other values might be defined in the future as technology advance.
Also here values with the format 1bbb.bbbb.bbbb.bbbb are left to
represent vendor specific or proprietary modulation formats.
6. Optical Path Parameters sub-TLV(s)
For each available channel, this set of parameters has to be carried
through the PATH message to allow the optical feasibility evaluation.
At each hop, the optical node will update these values according to
information locally available at the node (say internal amplifiers,
wavelength cross connect, etc.). The way an optical node gets
knowledge of this required information (e.g. through NMS, auto-
discovery etc.) is out of the scope of this document.
Martinelli & Zanardi Expires May 11, 2008 [Page 8]
Internet-Draft Optical Impairment Signaling November 2007
This document defines two groups of linear optical parameters. Each
group will have its own sub-TLV.
Mandatory Linear Optical Parameters
This set includes Optical Signal Power and the OSNR with
associated variances. It represents a minimum set to asses the
feasibility of an optical path. This set will be encoded using a
mandatory sub-TLV.
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 an
optional sub-TLV.
Separation between Mandatory and Optional 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
both sets of optical path parameters. With this separation, the
light-path signalling still continues to work with a less accurate
evaluation.
The choice of optional set of parameters depends on several
considerations. They are among those reported by the [RFC4054] and
provide sufficient accuracy for the linear impairments evaluation.
For each parameter an error estimation is associated (variance); if
no error estimation is provided the value MUST be zero.
6.1. Mandatory Linear Optical Parameters
The Sub-TLV encode the values of the optical parameters of the
channel (wavelength) associated to the TLV, measured at the node
egress interface.
Martinelli & Zanardi Expires May 11, 2008 [Page 9]
Internet-Draft Optical Impairment Signaling November 2007
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Optical Power |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Optical Power Variance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSRN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSNR Variance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
Type: sub-TLV type (TBA).
Flags: Mandatory, ToUpdate.
Length: length of the sub-TLV value in bytes.
Signal Optical Power. 32-bit IEEE floating point number.
Measurement Unit: dBm.
Signal Optical Power Variance. 32-bit IEEE floating point number.
OSNR. 32-bit IEEE floating point number. Measurement Unit: dB.
OSNR Variance. 32-bit IEEE floating point number.
6.2. Optional Linear Optical Parameters
The Sub-TLV encode the values of the optional optical parameters of
the channel (wavelength) associated to the TLV, measured at the node
egress interface. This Sub_TLV is defined as LSP_ATTRIBUTES.
Martinelli & Zanardi Expires May 11, 2008 [Page 10]
Internet-Draft Optical Impairment Signaling November 2007
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CD Variance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PMD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PMD Variance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CrossTalk |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CrossTalk Variance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
Type: sub-TLV type (TBA).
Flags: Optional, ToUpdate.
Length: length of the sub-TLV value in bytes.
CD, Chromatic Dispersion. 32-bit IEEE floating point number.
Measurement Unit: ps/nm.
CD Variance. 32-bit IEEE floating point number.
PMD, Polarization Mode Dispersion. 32-bit IEEE floating point
number. Measurement Unit: ps.
PMD Variance. 32-bit IEEE floating point number.
CrossTalk. 32-bit IEEE floating point number. Measurement Unit:
dB.
CrossTalk Variance. 32-bit IEEE floating point number.
7. 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-
Martinelli & Zanardi Expires May 11, 2008 [Page 11]
Internet-Draft Optical Impairment Signaling November 2007
TLV considering 3 FEC/modulation format combinations plus, 20 bytes
for the Mandatory Linear Optical Path parameters plus 28 bytes for
the Optional Linear Optical Parameter sub-TLV. Total is 44 bytes for
each wavelength by just considering mandatory sub-TLVs and 72 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 1408 to 2304 bytes.
One possible option is to let the application layer requesting the
light-path setup to decide how many wavelengths to signal. So, for
example, the application layer might ask to signal at most 10
wavelengths at a time to make sure the path message will stay within
the MTU limit for its network.
A second solution proposed here allows the semantic fragmentation as
suggested by RSVP [RFC2205]. The proposed encoding extends the
SENDER_TEMPLATE with new ClassType (derived from the LSP_TUNNEL_IPv4
and LSP_TUNNEL_IPv6 RSVP-TE [RFC3209]). The Object includes the
information on the "fragment id" and the requested policy at the
destination 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 6
Martinelli & Zanardi Expires May 11, 2008 [Page 12]
Internet-Draft Optical Impairment Signaling November 2007
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 7
Besides fields already defined in the SENDER_TEMPLATE, the following
fields are defined here:
o TotalNo: 8 bit integer representing the total number of Path
messages issued by the source node to setup a single light-path.
When this values is equals to 1 all the other fields MUST be
ignored.
o MsgId: 8 bit integer representing a sequential number of a single
Path request. Its value must be between 1 and TotalNo, both
inclusive.
o P: Policy the destination 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 arrived, wait for any messages
within the specified Timeout.
3: After the first message arrived, waits for all
messages. Fail, if the timeout expires, and there's at
least one message missing
The Destination 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 intermediate
Martinelli & Zanardi Expires May 11, 2008 [Page 13]
Internet-Draft Optical Impairment Signaling November 2007
nodes.
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.
8. Backward Compatibility
The TLV usage as defined by [RFC4420] 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
destination node. If an intermediate node does not support the
extensions the collected information is unreliable and the Path
request MUST be rejected.
9. Error management
No additional error code is introduced to manage requests failures;
the behavior defined in [RFC4420] applies to the management of the
LSP_REQUIRED_ATTRIBUTES Object.
10. Acknowledgements
11. 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 May 11, 2008 [Page 14]
Internet-Draft Optical Impairment Signaling November 2007
Gabriele Maria Galimberti Alberto Tanzi
Cisco Systems Cisco Systems
via Philips 12 via Philips 12
Monza 20052 Monza 20052
Italy Italy
Email: ggalimbe@cisco.com Email: atanzi@cisco.com
Domenico La Fauci Stefano Piciaccia
Cisco Systems Cisco Systems
via Philips 12 via Philips 12
Monza 20052 Monza 20052
Italy Italy
Email: dlafauci@cisco.com Email: spiciacc@cisco.com
Elio Salvadori Yabin Ye
CREATE-NET CREATE-NET
via della Cascata 56c, Povo via della Cascata 56c, Povo
Trento 38100 Trento 38100
Italy Italy
Email: elio.salvadori@create-net.org Email: yabin.ye@create-net.org
Chava Vijaya Saradhi
CREATE-NET
via della Cascata 56c, Povo
Trento 38100
Italy
Email: saradhi.chava@create-net.org
12. IANA Considerations
This memo needs the follwing request to IANA
TLV (see Figure 1 in Section 4)
New class type for sender template (see Section 7)
All drafts are required to have an IANA considerations section (see
the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
Martinelli & Zanardi Expires May 11, 2008 [Page 15]
Internet-Draft Optical Impairment Signaling November 2007
for a guide). If the draft does not require IANA to do anything, the
section contains an explicit 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.
13. 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.
14. References
14.1. Normative References
[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
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical
Martinelli & Zanardi Expires May 11, 2008 [Page 16]
Internet-Draft Optical Impairment Signaling November 2007
Transport Networks Control", RFC 4328, January 2006.
[RFC4420] Farrel, A., Papadimitriou, D., Vasseur, J., and A.
Ayyangar, "Encoding of Attributes for Multiprotocol Label
Switching (MPLS) Label Switched Path (LSP) Establishment
Using Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 4420, February 2006.
14.2. Informative References
[I-D.bernstein-ccamp-wavelength-switched]
Bernstein, G., "Framework for GMPLS and PCE Control of
Wavelength Switched Optical Networks",
draft-bernstein-ccamp-wavelength-switched-02 (work in
progress), October 2007.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-08 (work in
progress), October 2007.
[I-D.otani-ccamp-gmpls-lambda-labels]
Otani, T., "Generalized Labels of Lambda-Switching Capable
Label Switching Routers (LSR)",
draft-otani-ccamp-gmpls-lambda-labels-00 (work in
progress), July 2007.
[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.
Authors' Addresses
Giovanni Martinelli (editor)
Cisco Systems
via Philips 12
Monza 20052
Italy
Email: giomarti@cisco.com
Martinelli & Zanardi Expires May 11, 2008 [Page 17]
Internet-Draft Optical Impairment Signaling November 2007
Andrea Zanardi (editor)
CREATE-NET
via della Cascata 56c, Povo
Trento 38100
Italy
Email: andrea.zanardi@create-net.org
Martinelli & Zanardi Expires May 11, 2008 [Page 18]
Internet-Draft Optical Impairment Signaling November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Martinelli & Zanardi Expires May 11, 2008 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 01:58:42 |