CCAMP Working Group Zafar Ali
Internet Draft Roberto Cassata
Intended status: Standards Track Cisco Systems, Inc.
Marco Anisetti
Valerio Bellandi
Ernesto Damiani
Francesco Diana
Umberto Raimondi
University of Milan
T. Otani(KDDI R&D Laboratories, Inc.)
Expires: August 2008 February 25, 2008
Ping and Traceroute with Evidence Collection in Photonic Networks
draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.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 August 25, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
Z. Ali, et Al. Expires August 2008 [Page 1]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
[RFC4379] describes procedures for ping and tracerouting for LSPs
with PSC (packet switch capable) transit switching capability. An
important implication of using transparent (non-PSC) nodes in GMPLS
network is that LSP Ping solution described in [RFC4379] are not
applicable to LSP with non-PSC switching capability. Another
important difference between PSC and non-PSC switching technologies
is the data and control plan separation in the latter case. An
implication of the separation of data and control planes in GMPLS
networks is that LSP traceroute procedures described in [RFC4379] are
not directly applicable to GMPLS networks with separation of data and
control planes.
The scope of this draft is cases where data plane does not provide
the OAM functions addressed by this draft. This document is assumed
that OAM mechanisms provided by the underlying data plan technology
MUST be used, whenever possible. E.g., G.709 addresses the problem of
trace routing in DWDM network. However, G.709 OAM mechanisms are only
applicable to OEO (Optical-Electrical-Optical) capable node. This
document fills in such gaps; in particular it addresses GMPLS OAM
functionality in optical networks with wavelength routers, ROADMs
nodes, etc. with no OEO conversion capability. For this purpose, the
draft relies on control plan mechanism to provide required OAM
functions. Specifically the proposed solutions are based on Link
Management Protocol (LMP) [RFC4204] and RSVP-TE [RFC3209], [RFC3473]
and do not require any extension to the data plan.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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.
Table of Contents
1. Introduction................................................3
2. Tracerouting with Evidence Collection........................4
2.1. Optical Path Quality Evaluation.........................5
2.2. Optical Evidence Classification and LSP Locking..........6
2.3. Optical Evidence Collection.............................7
2.4. Evidence Collection Request TLV.........................8
2.5. Evidence recording TLV..................................8
2.6. Administrative Status Object extension..................9
Z. Ali, et al Expires August 2008 [Page 2]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
2.7. Signaling Procedure for tracerouting with evidence collection
...........................................................10
2.7.1. Tracerouting with non-blocking evidence collection.10
2.7.2. Tracerouting with blocking evidence collection and all
nodes ready for evidence collection......................11
2.7.3. Tracerouting with blocking evidence collection with some
node(s) blocked for evidence collection..................12
3. LSP Ping for GMPLS LSPs.....................................13
3.1. LSP Verification Procedure.............................15
4. Security Considerations.....................................15
5. Acknowledgments............................................16
6. References.................................................16
6.1. Normative References...................................16
6.2. Informative References.................................16
Author's Addresses............................................17
Intellectual Property Statement................................18
Disclaimer of Validity........................................18
1. Introduction
When a GMPLS LSP fails to deliver user traffic, the failure cannot
always be detected by the GMPLS control plane. There is a need to
provide a tool that would enable users to detect such traffic "black
holes" or misrouting within a reasonable period of time, and a
mechanism to isolate faults [GMPLS-OAM-REQ]. Similarly, ability to
traceroute a GMPLS LSPs in networks where data and control planes are
separated is a requirement [GMPLS-OAM-REQ]. This draft provides
solution to these requirements.
The scope of this draft is cases where data plane does not provide
the OAM functions addressed by this draft. This document is assumed
that OAM mechanisms provided by the underlying data plan technology
MUST be used, whenever possible. E.g., G.709 addresses the problem of
trace routing in DWDM network. However, G.709 OAM mechanisms are only
applicable to OEO (Optical-Electrical-Optical) capable node. This
document fills in such gaps; in particular it addresses GMPLS OAM
functionality in optical networks with wavelength routers, ROADMs
nodes, etc. with no OEO conversion capability. For this purpose, the
draft relies on control plan mechanism to provide required OAM
functions.
[RFC4379] describes control plan procedures for LSP Ping for LSPs
with PSC (packet switch capable) endpoint and transit switching
capability devices. LSP Ping solutions described in [RFC4379],
however, are not applicable to LSPs crossing or terminating non-PSC
switching capable devices. This is because the solution described in
RFC4379 requires all transit and end point nodes along the LSP path
Z. Ali, et al Expires August 2008 [Page 3]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
to be able to intercept the MPLS OAM (Operation and Maintenance)
packets and identify the Target FEC Stack being tested. Such
capability is not available at nodes that are non-PSC-capable.
Moreover, LSP ping mechanisms described in [RFC4379] can be
inadequate even when the end points of the GMPLS LSP are PSC-capable.
This is because the GMPLS LSP appears as a single hop for procedures
described in [RFC4379]. In such cases, mechanisms in [RFC4379] are
able to detect data plan failure in the GMPLS LSP but are still not
able to isolate failures in underlying switching layers.
The Link Management Protocol (LMP) [RFC4204] fault isolation
mechanism can be used to detect and isolate failures along a GMPLS
LSP, but it requires the GMPLS LSP to be carrying traffic. Inability
to use LSP fault isolation is a considerable limitation for operators
wanting to check the health of an LSP before carrying traffic over
it. This draft addresses this limitation by extending the LMP link
verification procedure to check connectivity of a GMPLS LSP and
extending the RSVP-TE to detect the faulty point.
For successful fault detection on a light-path, the fault isolation
mechanism must be aware of all physical evidence (consisting of
optical measurements such as signal power, OSNR, OCM (Optical Channel
Monitor), etc.) that have effect on the light-path. The proposed
technique is also suitable for optical networks that suffer of
physical dysfunction due the non-ideal optical transmission medium
and/or to critical situations (e.g., a fiber cut). In this scenario
even if every node along the path is connected, the reachability of
the end node with an acceptable signal quality is not guaranteed.
Such evidence can consist of real optical measurements or estimates
computed via a prediction model. The former may require mutually
exclusive access to hardware to avoid interference; therefore,
evidence can also be classified as blocking or non-blocking. This
draft address both type of evidence collections. Furthermore, in this
draft evidence collection is performed during the phase of trace
routing.
2. Tracerouting with Evidence Collection
Traceroute is often used for network troubleshooting. Specifically,
it is used identify the LSP taken to reach a particular destination
viewing the all transit nodes on the network; for that reasons it is
used also to detect faulty point inside a route.
The LSP traceroute procedures described in [RFC4379] are not directly
applicable to GMPLS networks with separation of data and control
planes. To overcome this issue tracerouting using RSVP RRO object
Z. Ali, et al Expires August 2008 [Page 4]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
[RFC4561] can be implemented. This strategy is only a control plain
view. However, maintain a coherence with data channel in the sense of
traversed nodes it detects a faulty point in the control channel that
is largely different than finding the faulty point in the data
channel.
This draft proposes a technique to address the deficiency of the use
of RRO for tracerouting a GMPLS LSP. The proposed is control plan
based but is able perform a traceroute with fault isolation coherent
with data channel. The proposed method is able to perform
tracerouting with evidence collection. It is based on the idea that
for successful fault detection on an optical path, the fault
isolation mechanism must be aware of all physical evidence
(consisting of optical measurements such as signal power, OSNR,
Optical Channel Monitor, etc.) that have effect on the light-path.
Therefore measuring or estimating some physical evidences along an
optical path address the actual control channel deficiency in finding
the data channel coherence traceroute.
2.1. Optical Path Quality Evaluation
The quality of an optical path is done by collecting the physical
evidences along an LSP and evaluating them (e.g. for faulty point
detection). As already mention this feature integrates the
tracerouting in such a way that the control channel becoming aware
and coherent with data channel. The holistic analysis proposed
produce also a quality of path awareness.
In this draft we extend the LSP_ATTRIBUTES to perform the evidence
collection hop by hop.
Other important concept defined by this evidences collection process
is that certain evidences (blocking evidence) require a mutually
exclusive access. Therefore the entire LSP needs to be locked until
the evidence collection process is performed. This implies that if
other evidence collection process tries to retrieve evidences on the
same node-resource already under Administrative Evidences Locking
status, it MUST be aborted. The draft uses RSVP Admin status object
to define LSP Administrative Evidences Locking status and to make
sure that all nodes are ready to collect the blocking evidence.
In the following we first define Optical Evidence classification, and
extension to LSP ATTRIBUTE and RSVP Admin status objects needed to
perform above mentioned functionalities. The later sections details
Z. Ali, et al Expires August 2008 [Page 5]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
signaling procedures with examples on how these objects are used for
tracerouting with evidence collection.
2.2. Optical Evidence Classification and LSP Locking
Physical evidences (consisting of optical measurements such as signal
power, OSNR, Optical Channel Monitor, etc.) that have effect on the
light-path are classified as:
o Blocking evidence. In general blocking evidence is a physical
measurement that may require a mutually exclusive access to hardware
resources while performing the measurement.
o Non blocking evidence. Every physical values that can be probed in
parallel with different RSVP-TE.
Every optical Node can be in three states related to a certain
reserved resource: unlock, lock-required or lock. In fact blocking
evidence MUST generate a lock on each reserved resource required for
evidence reading. In general this is due to the hardware limitation
of optical nodes.
In case of blocking evidence the LSP status needs to be set to
"Locked". To perform this status changing we use the Admin object
[RFC3471] with B bit (Blocked bit) and C bit (block Confirm)
extension. In our LSP locking strategy also the R bit (Reflect bit)
MUST be set since the egress node MUST return the Admin object in the
Resv Message for locking confirmation or unlocking. Since we need to
block an entire LSP, one node unable to measure the required blocking
evidence MUST generate a lock failure (unset the C bit in the Path
Admin Object). Therefore the evidence locking is considered
mandatory.
The general locking procedure is defined as follow:
o Every transit node that receives the Admin status object in the
Path message with B, C and R bit set needs to check if the actual
status is unlock.
o In the case of unlock status, the node switches to lock-required
state related to the required blocking evidence.
o In the case of lock or lock-required statuses, the node forwards
the Admin object message without the C bit set. This implies a lock
failure.
Z. Ali, et al Expires August 2008 [Page 6]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
o The Resv message performs the locking for the entire LSP in case
of C and B bit set and unlocking in case of unset C bit.
o Every transit node that receives the Resv message with B and C bit
set changes its status to lock.
This strategy prevents race conditions.
2.3. Optical Evidence Collection
Path quality evaluation is based on holistic analysis of the evidence
collected inside an LSP. To determinate which evidence needs to be
collected we adopt a LSP Attribute TLV sub-object.
The evidence collection is performed as follows:
o Source node sends a Path message with LSP Attribute object aimed
to inform the transit nodes about the imminent evidence collection
This downstream Path message also contains TLV sub-object with
required evidence.
o Every transit node, when receives the message with LSP Attribute
object, assembles the collected evidence (specified in TLV) inside a
sub-TLV. The way an optical node gets knowledge of the evidence using
information locally available at the node (e.g. via discovery of
internal amplifiers, photodiode etc.) is out of the scope of this
document.
o Evidence collection will be executed by the returning Resv message
that collects hop-by-hop evidence objects upstream by inserting the
sub-TLV inside the attached TLV. After successful forwarding of Resv
message the status of transit nodes MUST be switched to unlock for
preventing deadlock.
In case of blocking evidence the LSP lock MUST be performed before
evidence collection.
In case of non-blocking evidence the unavailability of certain
evidence in an intermediate node MUST NOT cause the request of
failure (PathErr message) since the holistic evidence evaluation
SHOULD be able to deal with missing non-blocking evidence.
When one transit node not in locking state receives a request for
blocking evidence, an evidence collection failure (PathErr) MUST be
triggered.
Z. Ali, et al Expires August 2008 [Page 7]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
2.4. Evidence Collection Request TLV
NOTE: INFORMATION IN THIS SECTION NEED SOME CAREFUL REVISION AGAINST
EXPECTED USAGE IN [RFC4420].
The proposed encoding scheme for optical evidence measurements
defines a TLV associated to a particular evidence type. A TLV sub-
object is encoded in an LSP_REQUIRED_ATTRIBUTES Object [RFC4420]. The
TLV sub-object encoding is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E-Type | Reserve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Collected evidence type(TBA). Can be blocking or non blocking
type.
Length: length of the TLV object in bytes without the 4 byte header.
E-type (Evidence Type, 8 bits): Evidence identifier, for instance: 0
as Signal power, 1 as OSNR, 2 as Pilot Tone (as blocking evidence).
This TLV defines which type of evidence needs to be collected and
specifies the evidence (signal power, OSNR, Pilot Tone, alarm etc.)
in the Path message.
2.5. Evidence recording TLV
NOTE: INFORMATION IN THIS SECTION NEED SOME CAREFUL REVISION AGAINST
EXPECTED USAGE IN [RFC4420].
For provisioned LSP, a set of evidence has to be collected through
the Resv message to allow the optical quality evaluation at the
ingress node. Each item of optical evidence is collected separately.
Every transit node, in the Path message, finds the Evidence
collection requested TLV and stores in the Evidence recording TLV
(encoded in an LSP_ATTRIBUTES Object) its own measured or estimated
value. Furthermore it sets the Measure Method inside the this TLV
according to the kind of measured media (single lambda measurement or
aggregate measurement).
This evidence collection improves the feasibility evaluation where
network elements support at least only a subset of evidence.
The following TLV encode the evidence's values of the LSP associated
to the evidence type defined in the Evidence Collection Request TLV.
Z. Ali, et al Expires August 2008 [Page 8]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4/IPv6 Address/unnumbered |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Evidence Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Measure Method | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Evidence type(TBA).
Length: length of the TLV value in bytes.
IPv4/IPv6 Address: The address of the Node that measures the
evidence.
Evidence Value: Estimated or measured evidence value. For instance
the Signal Optical Power as 32-bit IEEE floating point number.
Measure(ment) method: Aggregate measurement (0) or single lambda
measurement (1).
2.6. Administrative Status Object extension
We propose and extension to Administrative status object by adding
two bits for locking purpose.
Therefore the format of the extended Admin_Status Object is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |C|B|T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reflect (R): 1 bit
When set, indicates that the edge node SHOULD reflect the object/TLV
back in the appropriate message. This bit MUST NOT be set in state
change request, i.e., Notify, messages.
Z. Ali, et al Expires August 2008 [Page 9]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
Reserved: 25 bits. This field is reserved. It MUST be set to zero on
transmission and MUST be ignored on receipt. These bits SHOULD be
passed through unmodified by transit nodes.
Testing (T): 1 bit. When set, indicates that the local actions
related to the "testing" mode should be taken.
Administratively down (A): 1 bit. When set, indicates that the local
actions related to the "administratively down" state should be taken.
Deletion in progress (D): 1 bit. When set, indicates that that the
local actions related to LSP teardown should be taken. Edge nodes
may use this flag to control connection teardown.
Blocking node (B): 1 bit. When set, indicates that locking procedure
is ongoing.
Confirm blocking (C): 1 bit. When set, indicates that an the locking
procedure is successfully ongoing.
2.7. Signaling Procedure for tracerouting with evidence collection
In this section we describe signaling procedures for tracerouting
with evidence collection using examples. Consider a GMPLS LSP that
has OXC1 as Ingress Node, OXC4 as Egress node with OXC2 and OXC3 in
transit, as shown below.
+------+ +------+ +------+ +------+
| | ----- | | ===== | | ----- | |
| OXC1 | ===== | OXC2 | ----- | OXC3 | ----- | OXC4 |
| | ----- | | ----- | | ===== | |
+------+ +------+ +------+ +------+
In the following we consider three scenarios of evidence collection
and describe signaling procedures associated with the evidence
collection and how above mentioned extensions to LSP Attribute and
admin status objects are used for this purpose.
2.7.1. Tracerouting with non-blocking evidence collection
The quality evaluation of an optical path is done after LSP
provisioning and in case of non-blocking evidences is implemented by
the following procedure:
Z. Ali, et al Expires August 2008 [Page 10]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
o OXC1 node sends a Path message with Evidence Collection Request
TLV aimed to inform the transit nodes about the imminent evidence
collection and about the type of evidence that needs to be collected
(e.g., Signal power).
o The transit nodes that do not support LSP_REQUIRED ATTRIBUTE
object or do not support evidence request TLV will be addressed in a
later version of the document.
o Every transit node (OXC2,OXC3), when receives the Path message
with Evidence Collection Request TLV, starting the internal evidence
reading procedure and waits for the correspondent Resv message to
forward the related Evidence recording TLV in the upstreaming flow to
the ingress node OXC1. If for some reason the evidence is not
available, since it is non blocking evidence, the node simply do not
include the evidence measure in its own Evidence recording TLV. The
holistic analysis can be performed also with a subset of the non
blocking evidences.
o Egress node OXC4 sends Resv message with Evidence Collection
Request TLV containing optical evidence TLV upstream to the ingress
node OXC1 and puts its own evidence value in this Evidence recording
TLV.
o Every transit node (OXC3,OXC2) inserts its own Evidences recording
TLV inside Resv message in such way that ingress node collects all
required evidences hop by hop using the upsteaming flow.
o OXC1 node when receives the Resv message extract the Evidences
recording TLV to perform holistic path quality analysis.
Summarizing the Evidence collection will be executed by the returning
Resv message that collects hop-by-hop evidence objects upstream.
2.7.2. Tracerouting with blocking evidence collection and all nodes
ready for evidence collection
In this scenario the locking strategy needs to be performed first to
be sure that no one node in the LSP is already locked in another
blocking evidences collection. Summarizing we need to be sure that
all nodes along the path are ready to collect the evidence. This
phase uses Admin status object in the path and Resv message to
The locking procedure is defined as follow:
o OXC1 switches to lock-required state and sends a Path message with
Admin status object with B, C and R bit set. B bit is used for
Z. Ali, et al Expires August 2008 [Page 11]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
locking requirement. C bit is used for locking confirmation if set
and for unlock if unset.
o Every transit node (OXC2, OXC3) that receives the Admin status
object in the Path message with B, C and R bit set switches to lock-
required state related to the required blocking evidence.
o Egress node OXC4 switches to lock state forward the Admin status
object in the Resv message resetting the R bit.
o Every transit node (OXC3,OXC2) that receives the Resv message with
B and C bit set changes its status to lock.
o Ingress node OXC1 when receive the Resv message with Admin status
object with B and C bit set switches to lock states.
At the end of this procedure the entire LSP is in lock state and is
ready for blocking evidence collection.
At this stage the Evidence collection can be performed as described
in the Section 2.7.1 except that every transit nodes need to change
its own status to unlock to prevent deadlock as described in the
Evidence collection Section (2.3).
The locking strategy is performed before evidence collection to
maintain a better compatibility with the future available blocking
evidences kind that would require further action to be taken before
starting the collection.
2.7.3. Tracerouting with blocking evidence collection with some node(s)
blocked for evidence collection.
In this scenario the locking procedure fails since some nodes (e.g
OXC3 is in locking or lock-required state over other LSP)
o OXC1 switches to lock-required state and sends a Path message with
Admin status object with B, C and R bit set. B bit is used for
locking requirement. C bit is used for locking confirmation if set
and for unlock if unset.
o OXC2 receives the Admin status object in the Path message with B,
C and R bit set switches to lock-required state related to the
required blocking evidence.
Z. Ali, et al Expires August 2008 [Page 12]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
o OXC3 node when receives the Admin status object since it is
already lock or lock-required over other LSP with the same resources,
unset the C bit. Therefore the locking procedure will fails.
o Egress node OXC4 since receives the Admin object without C bit set
switches to unlock state and forwards the received Admin status
object in the Resv message resetting the R bit.
o Other transit nodes (OXC3, OXC2) when receive the Admin object in
the Resv message with B bit set but with C bit unset, switch to
unlock state.
o The ingress node OXC1 when receives Resv message with Admin object
containing B bit set and C bit unset switches to unlock.
At this stage the Locking strategy is failed since the ingress node
does not receive the confirmation of successful locking (C bit set).
3. LSP Ping for GMPLS LSPs
Tracerouting with evidence collection described in the last section
is an expensive signaling operation. Most of the time service
provider's requirement is to test connectivity verification, and to
perform tracerouting with evidence collection when detailed
diagnostic of LSP is needed.
If the end-points of the LSP are PSC capable, LSP ping procedure in
[RFC4379] can be used. However, if LSP end-points are non-PSC
capable, LMP procedure described in this section can be used to
provide LSP ping functionality for GMPLS LSPs. For this purpose, this
draft proposes an extended LMP model as shown below.
+------+ +------+ +------+ +------+
| | ----- | | ===== | | ----- | |
| OXC1 | ===== | OXC2 | ----- | OXC3 | ----- | OXC4 |
| | ----- | | ----- | | ===== | |
+------+ +------+ +------+ +------+
^ ^ ^ ^ ^ ^ ^ ^
| | | | | | | |
| +----LMP1----+ +----LMP2---+ +-----LMP3----+ |
| |
+----------------------LMP4----------------------+
Z. Ali, et al Expires August 2008 [Page 13]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
Figure 1 Extended LMP Model.
In this model, non-adjacent nodes may establish and maintain LMP
sessions that can be used to check the status of a GMPLS LSP. Also,
the nodes continue to maintain hop-by-hop LMP sessions to build
traffic-engineering (TE) links for GMPLS signaling and routing, as
described in [RFC4204]. For example in Figure 1, OXC1-OXC2, OXC2-
OXC3, and OXC3-OXC4 LMP sessions are used to build traffic-
engineering (TE) links for GMPLS signaling and routing, while the LMP
session OXC1-OXC4 (LMP4) is used to monitor the health of GMPLS
LSP(s) with OXC1 and OXC4 as end-points. Note that the LMP session
between LSP end-point nodes is only used for OAM purposes. Existing
signaling mechanisms are used to discover remote link property.
Once an LMP session between LSP end-point nodes comes up, Link
connectivity verification can be used to perform LSP connectivity
verification. This is done by sending Test messages over the GMPLS
LSP and TestStatus messages back over the control channel. For this
purpose, LMP connectivity verification procedure as described in
[RFC4204] is used. Note that in this model the verification of a
GMPLS LSP is not confined to LSPs having endpoint nodes that are PSC-
capable, but effectively to LSPs of endpoint nodes that reside at any
of the GMPLS switching layers.
In what follows, we outline how existing LMP and MPLS OAM procedures
needs to be applied to provide tracerouting functionality in
scenarios outlined above. Again recall the scope of this draft is
cases where data plane does not provide the OAM functions addressed
by this draft.
The control channel management for LSP ingress-node-to-egress-node is
the same as described in [RFC4204]. To distinguish between a LSP
ingress-node-to-egress-node LMP session and a peer node-to-peer node
LMP session, a new LMP_TARGET_HELLO_CONFIG object is defined (C-Type
= TBD). The format of the CONFIG object is as follows:
Class = TBD
o C-Type = TBD, LMP_TARGET_HELLO_CONFIG
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Z. Ali, et al Expires August 2008 [Page 14]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
The Reserved field should be sent as zero and ignored on receipt.
T: 1 bit
This bit indicates support for the LMP-LSP-Verification extensions
defined in this document.
To establish an ingress-node-to-egress-node LMP session, sender node
uses the control plane's IP address of the LSP destination node,
while sending the LMP_TARGET_HELLO_CONFIG message. The ConfigAck and
ConfigNack messages MUST be sent to the source IP address found in
the IP header of the received Config message.
3.1. LSP Verification Procedure
Link verification procedure described in [RFC4204] has been adapted
for LSP verification. Specifically, once a control channel has been
established between the ingress and egress nodes of an LSP, LSP
connectivity can be verified by exchanging Test messages between
nodes along the GMPLS LSP's path. Since the LSP's health can be
tested along the forwarding transmit path, both endpoints nodes can
(independently and simultaneously) initiate the exchange of Test
messages in each direction to test for the health of bidirectional
LSPs.
To initiate the link verification procedure, the Ingress (Egress)
node MUST send a BeginVerify message over a control channel with the
IP address of the destination (source) node of the LSP. To limit the
scope of LSP Verification to a particular LSP, the local Lsp_Id
assigned by the local node is used. This Lsp_Id is learned by the
remote node during signaling and MUST be non-zero. If this field is
zero, the verification can span multiple TE LSPs between the set of
Ingress/Egress nodes involved in the verification process. The rest
of the details for LSP verification are the same as described for
link verification in [RFC4204].
4. Security Considerations
Security considerations and requirements form [RFC4204] and [RFC4379]
apply equally to this document. Furthermore, there are some
additional security considerations that may be induced by extended
Z. Ali, et al Expires August 2008 [Page 15]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
LMP model and RSVP-TE proposed by this draft. These security
considerations will be added in a later version of the draft.
5. Acknowledgments
Authors would like to thank Alberto Tanzi, Ferdinando Malgrati,
Domenico La Fauci, Enzo Luca Passerini, Gabriele Galimberti for their
valuable inputs.
6. IANA Considerations
TBA.
7. References
7.1. Normative References
[RFC4204] Lang, J., et al., "Link Management Protocol (LMP)", RFC
4204, October 2003.
[RFC4379] Kompella, K., Swallow, "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", RFC 4379, February 2006
[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., et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., et al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling", RFC 3473, RFC 3473, January 2003.
[RFC4561] Vasseur, J.-P.,Ali, Z., Sivabalan, S., "Definition of a
Record Route Object (RRO) Node-Id Sub-Object", RFC 4561, June 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.
7.2. Informative References
[GMPLS-OAM-REQ] Otani, T., et al., "OAM Requirements for Generalized
Multi-Protocol Label Switching (GMPLS) Networks", draft-ietf-ccamp-
gmpls-oam-requirements-00.txt.
Z. Ali, et al Expires August 2008 [Page 16]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
Author's Addresses
Zafar Ali
Cisco Systems, Inc. 200
100 South Main St. #
Ann Arbor, MI 48104
USA
Email: zali@cisco.com
Marco Anisetti
University of Milan, Department of information Technology
Via Bramante 65, 26013 Crema (CR)
Italy
Email: anisetti@dti.unimi.it
Valerio Bellandi
University of Milan, Department of information Technology
Via Bramante 65, 26013 Crema (CR)
Italy
Email: bellandi@dti.unimi.it
Roberto Cassata
Cisco Systems, Inc.
Via Philips 2, 20052 Monza (MI)
Italy
Email: rcassata@cisco.com
Ernesto Damiani
University of Milan, Department of information Technology
Via Bramante 65, 26013 Crema (CR)
Italy
Email: damiani@dti.unimi.it
Francesco Diana
University of Milan, Department of information Technology
Via Bramante 65, 26013 Crema (CR)
Italy
Email: diana@dti.unimi.it
Tomohiro Otani
KDDI R&D Laboratories, Inc.
2-1-15 Ohara Fujimino Saitama, 356-8502. Japan
Email: otani@kddilabs.jp
Umberto Raimondi
Z. Ali, et al Expires August 2008 [Page 17]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
University of Milan, Department of information Technology
Via Bramante 65, 26013 Crema (CR)
Italy
Email: uraimondi@crema.unimi.it
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Z. Ali, et al Expires August 2008 [Page 18]
Internet-Draft draft-ali-ccamp-gmpls-lsp-ping-traceroute-01.txt Nov.07
Z. Ali, et al Expires August 2008 [Page 19]