One document matched: draft-shiomoto-ccamp-misconnection-analysis-00.txt
CCAMP Working Group K. Shiomoto (NTT)
Internet Draft V. Sharma (Metanoia, Inc.)
Document: draft-shiomoto-ccamp- Y. Suemura (NEC)
misconnection-analysis-00.txt
Expires: December 2004 June 2004
Analysis of Misconnection Scenarios in GMPLS Networks
draft-shiomoto-ccamp-misconnection-analysis-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Abstract
The purpose of this memo is to describe and analyze the occurrence of
misconnections in GMPLS networks. We present a problem statement,
and describe some scenarios under which misconnections may happen. We
then outline some common causes of misconnections and discuss some
solutions to address them. Our goal is to facilitate further
discussions of this issue and the associated solutions within the
CCAMP Working Group.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................2
3. Problem Statement..............................................2
4. Analysis of Misconnection Scenarios............................3
4.1. Activating Backup LSPs in Shared Mesh/1:1 Restoration........3
4.2. Activating High-priority versus low-priority LSPs............5
4.3. Failure at a switch or node..................................7
Shiomoto/Sharma/Suemura Expires December 2004 1
Analysis of Misconnection Scenarios June 2004
in GMPLS Networks
5. Common Causes of Misconnections................................8
6. Possible Solutions to Handle Misconnections....................9
7. Conclusions....................................................9
8. Security Considerations.......................................10
9. References....................................................10
9.1. Normative References..............Error! Bookmark not defined.
9.2. Informative References............Error! Bookmark not defined.
10. Author's Addresses..........................................10
11. Intellectual Property Considerations........................11
11.1. IPR Disclosure Acknowledgement..............................11
12. Full Copyright Statement....................................11
1. Introduction
As providers gain experience with MPLS deployments, and begin
utilizing their MPLS/GMPLS networks as a common infrastructure upon
which to offer a variety of converged services (e.g., Layer 2
transport over MPLS, Layer 2 and Layer 3 MPLS VPNs, VoIP services,
and critical business data transport), a number of different aspects
related to MPLS/GMPLS network stability, operations, and management
become increasingly important.
In particular, with new restoration methods and sophisticated pre-
emption schemes that are possible, providers are interested in
understanding the nature and types of misconnections that may occur
in GMPLS-based networks, and in developing ways to either prevent
misconnections (where possible) or to detect misconnections and
minimize their impact in a timely manner on the network operations
and the services offered.
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 [1].
3. Problem Statement
Based on the description in Section 1, our problem can be stated as:
"To analyze when and how misconnections may happen during the
activation of LSPs in an GMPLS network; to identify some common
causes of misconnections; and, to propose some initial solutions for
avoiding or minimizing misconnections."
The purpose of this document, therefore, is to focus on
misconnections, and discuss when they may occur and evaluate some of
their common causes. The goal is also to propose some initial
solutions to address the problem of misconnections.
Shiomoto/Sharma/Suemura Expires December 2004 2
Analysis of Misconnection Scenarios June 2004
in GMPLS Networks
4. Analysis of Misconnection Scenarios
Misconnections in an MPLS/GMPLS network may happen in a variety of
circumstances. In the following sections, we focus on three cases of
misconnections that we have identified during discussions on the
CCAMP WG mailing list. These include:
i) Misconnections during the activation of a backup LSP in a shared
mesh or 1:1 restoration scenario.
ii) Misconnections during the activation of a high-priority LSP in
favor of a low-priority one.
iii) Misconnections due to a failure at a node or a switch.
4.1. Activating Backup LSPs in Shared Mesh/1:1 Restoration
A misconnection may occur in several ways during the activation of a
backup LSP in shared mesh restoration [3], [4], [5].
We discuss three cases below with an example setup.
Consider the following network scenario:
A-----------B
\ /
C-------D
/ \
E F
Where A-B: Path of the Primary LSP
A-C-D-B: Path of the Secondary LSP
E-C-D-F: Path of an Extra (preemptible) LSP
Case 1:
Assume that an LSP is always activated upon the receipt of a Path
message, and assume that initially the primary LSP A-B, and the
extra-traffic LSP E-C-D-F are active. Upon a failure in the primary
LSP, it is necessary to activate the secondary LSP A-C-D-B.
We consider what happens at node C upon the arrival of a Path message
(that signals the secondary LSP A-C-D-B) carrying a Protection Object
[2]. If node C immediately reconfigures its cross-connect to connect
A-C to C-D, then, for a short period of time (until node D receives
the Path message and reconfigures its cross-connect to connect C-D to
D-B), it is possible for traffic from A to end-up at F via the path
A-C-D-F, thus leading to a misconnection.
One way to eliminate this would be to have a two-way activation
scheme that makes use of both the Path and the Resv messages. For
example, the extra LSP E-C-D-F is deleted upon the receipt of a Path
message (that corresponds to the secondary LSP) at a node, while the
secondary LSP A-C-D-B is activated upon the receipt of a Resv message
(that corresponds, as before, to the secondary LSP) at a node. Thus,
Shiomoto/Sharma/Suemura Expires December 2004 3
Analysis of Misconnection Scenarios June 2004
in GMPLS Networks
in the example above, upon the detection of a failure on the primary
LSP A-B, a Path message with the Protection Object is sent along the
secondary LSP. Upon receipt of this message, node C deletes the
extra-LSP (removing state for it both from the control plane and the
data plane), and activates the secondary LSP when it receives a Resv
message for the secondary LSP.
However, even in this case a misconnection may happen as follows.
A-----------B
\ /
C-------D
/ \
E F
Where A-B: Path of the Primary LSP
A-C-D-B: Path of the Secondary LSP
E-C-D-F: Path of an Extra (preemptible) LSP
Case 2:
Assume that upon the receipt of a Path message(containing the
Protection Object) at node C, corresponding to the secondary LSP, the
cross-connect for the extra LSP is deleted.(Recall that both Path and
Resv messages must be periodically transmitted along the secondary
LSP to maintain the state of the provisioned secondary LSP.)
If node C now receives a Resv message from node D, it may set up the
cross-connect for the secondary LSP, thus connecting A-C to C-D. This
could happen, for example, when node C has no way of distinguishing a
refreshing Resv message (corresponding to the provisionedsecondary
LSP) whose purpose is merely to maintain state for this LSP from an
activating Resv message (corresponding to the secondary LSP) whose
purpose is to actually activate the secondary LSP, by causing
intermediate nodes to reconfigure their cross-connects. Therefore, if
the cross-connect at node C for the secondary LSP is (erroneously)
made before node D has had a chance to delete the cross-connect
corresponding to the extra LSP, there is a misconnection, with
traffic from node A ending up at node F via the path A-C-D-F.
A possible solution to this would be to also carry the Protection
object in the Resv message that is sent to activate the secondary
LSP, thus allowing a node to distinguish between a Resv message for
activation from a refresh Resv message, say via the S bit in the
Protection object.
Even when the above changes to the Resv object and the processing
rules are made, there remains the possibility of misconnections
because the nodes may not consistently bring down the state of the
extra- LSP. We explain this next.
Shiomoto/Sharma/Suemura Expires December 2004 4
Analysis of Misconnection Scenarios June 2004
in GMPLS Networks
A-----------B
\ /
C-------D
/ \
E F
Where A-B: Primary LSP
A-C-D-B: Secondary LSP
E-C-D-F: Extra (preemptible) LSP
Case 3:
Consider again the earlier network example, where we assume that the
Resv message is enhanced to carry the Protection object, and that the
cross-connections for the secondary LSP at a node are made upon the
receipt of the Resv message for activation.
Note that because of the way vendors interpret and implement rules
for hard/soft pre-emption of LSPs, it is possible that the extra LSP
is not brought down upon the receipt of the Path message for the
secondary LSP.
Thus, it is possible that node C, upon receipt of a Path message for
the secondary LSP, does not immediately delete the extra LSP.
Suppose node D, upon the receipt of a Resv message with a Protection
Object for the secondary LSP, brings down the extra LSP, and
activates its cross-connect for the secondary LSP, that is, it
reconfigures its cross-connect to switch from C-D -> D-F to C-D -> D-
B. However, since node C may not have deleted its cross-connect
corresponding to the extra LSP, traffic may now be misconnected from
node E to node B via the path E-C-D-B.
This may be prevented by enforcing a rule that an intermediate node
along the route of a secondary LSP must remove the state, in control
plane and data planes, associated with the extra LSP (that uses
resources required by the secondary LSP) *before* forwarding the Path
message for the secondary LSP.
4.2. Activating High-priority versus low-priority LSPs
The situations that lead to misconnections during the activation of
LSPs with different priorities are almost analogous to those that
arise in the shared mesh restoration case for activation of the
secondary LSP in place of the extra LSP. In fact, we have three cases
here that parallel those discussed in Section 4.1.
Consider the following network scenario:
A-----------B
\ /
Shiomoto/Sharma/Suemura Expires December 2004 5
Analysis of Misconnection Scenarios June 2004
in GMPLS Networks
C-------D
/ \
E F
Where
A-C-D-B: High-priority LSP
E-C-D-F: Low-priority LSP
Assume that initially LSP E-C-D-F is active, and that there is then a
need to set up the higher priority LSP A-C-D-B.
Case 1:
Assume that an LSP is always activated upon the receipt of a Path
message, and that initially the low-priority LSP E-C-D-F is active.
At some time, it becomes necessary to activate the high-priority LSP
A-C-D-B.
We consider what happens at C upon the arrival of Path message (that
signals the high-priority LSP A-C-D-B). If node C immediately
reconfigures its cross-connect to connect A-C to C-D, then, for a
short period of time (until node D receives the Path message and
reconfigures its cross-connect to connect C-D to D-B), it is possible
for traffic from A to end-up at F via the path A-C-D-F, thus leading
to a misconnection.
A possible solution to this is to, as before, use a two-way
activation scheme that uses both the Path and the Resv messages with
a way to distinguish between Resv messages that refresh the state of
an LSP from Resv messages that are supposed to activate the
configuration of a cross-connect for an LSP.
A-----------B
\ /
C-------D
/ \
E F
Where
A-C-D-B: High-priority LSP
E-C-D-F: Low-priority LSP
Case 2:
Consider again the earlier network example, where we assume that the
Resv message is enhanced to distinguish a refresh Resv message from a
Resv message for activation of an LSP. In other words, the cross-
connections for an LSP at a node are made upon the receipt of the
Resv message for its activation.
Note that because of the way vendors interpret and implement rules
for hard/soft pre-emption of LSPs , it is possible that the low-
Shiomoto/Sharma/Suemura Expires December 2004 6
Analysis of Misconnection Scenarios June 2004
in GMPLS Networks
priority LSP is not brought down upon the receipt of the Path message
for the high-priority LSP.
Thus, it is possible that node C, upon receipt of a Path message for
the high-priority LSP A-C-D-B, does not immediately delete the low
priority LSP E-C-D-F.
If node D, upon the receipt of a Resv message for the high-priority
LSP, brings down the low-priority LSP, and activates its cross-
connect for the high priority LSP, that is, it reconfigures its
cross-connect to switch from C-D -> D-F to C-D -> D-B, then we could
have a misconnection. This is because node C may not have deleted its
cross-connect corresponding to the low priority LSP, so traffic may
now be misconnected from E to B via the path E-C-D-B.
This may be prevented by enforcing a rule that an intermediate node
along the route of a high-priority LSP must remove the state, in the
control plane and data planes, associated with a low-priority LSP
(that uses resources required by the high-priority LSP) before
forwarding the Path message for the high-priority LSP.
4.3. Failure at a switch or node
Another situation when misconnections may arise is when a node or a
switch malfunctions. The nature of malfunctions could span the
control plane or the data plane.
Let us consider again the network scenario from Section 4.1.
A-----------B
\ /
C-------D
/ \
E F
where A-B: Primary LSP
A-C-D-B: Secondary LSP
E-C-D-F: Extra (preemptible) LSP
Suppose that we follow the rule of activating the secondary LSP upon
the receipt of a Resv message.
If there is a malfunction at node C, such that upon the receipt of a
Path message for the secondary LSP, it deletes the state of the extra
LSP from its control plane but fails to alter its cross-connect in
the data plane, thus allowing E-C to remain connected to C-D, we can
have a misconnection as follows.
Node D, upon receiving a Resv message (with a Protection object) from
node B, correctly switches its cross-connect from C-D -> D-F to C-D
-> D-B. However, since the cross-connect at C has not been altered,
traffic may now flow incorrectly from E to B via the path E-C-D-B.
Shiomoto/Sharma/Suemura Expires December 2004 7
Analysis of Misconnection Scenarios June 2004
in GMPLS Networks
If the control plane at C is somehow disconnected from its data
plane, with neither plane having stopped working, this situation
could continue indefinitely. It would then be necessary to have a way
to quickly detect and recover from such a misconnection scenario.
5. Common Causes of Misconnections
When examining the common causes of misconnections, there are two
issues to keep in mind:
- One issue is when (in time) a cross-connection is made.
- Second issue is the signaling method and rules used to drop
an extra LSP and activate a secondary LSP (in the restoration
case), or to activate a high-priority LSP and deactivate a
low-priority LSP.
-
In order to analyze the common causes of misconnections, we
distinguish between the logical association of an incoming port with
an outgoing port from the physical association.
The logical association is an association between the incoming and
outgoing ports that is stored in the MPLS/GMPLS controller software.
On the other hand, the physical association is the actual association
between the incoming and the outgoing ports. When a physical
association between two ports is made, the data traffic is
immediately carried from the incoming port to the outgoing port over
the cross-connection made by the physical association.
The case where low-priority traffic is preempted by high-priority
traffic is explained by noting the difference between the logical
association and the physical one. Suppose the low-priority traffic
has a logical association between an incoming port (say, port-i1) and
an outgoing port (say, port-o1), while the high-priority traffic has
a logical association between an incoming port (say, port-i2) and the
outgoing port (say, port-o1). The outgoing port (port-o1) is shared.
The logical association for the traffic is maintained by the
signaling protocol. If both logical associations exist, the logical
association for the high priority traffic is selected to make the
cross-connection and realize a physical association between port i2
and port o1. If a logical association for only the low priority
traffic exists, it is selected to make the cross-connection. That is,
a physical association is made between port i1 and port o1.
A common cause of misconnection lies in the situation where the
priority traffic selected to make the cross-connection is
inconsistently selected among the nodes along with the route.
Here we define the possible states for the cross-connection as:
(1) high,
(2) low, and
(3) null.
Shiomoto/Sharma/Suemura Expires December 2004 8
Analysis of Misconnection Scenarios June 2004
in GMPLS Networks
High and low states indicate that the cross-connection is made
according to the logical association of the high and low priority
traffic, respectively. Null state indicates that no cross-connection
is made (i.e., no input and output ports associated with low and high
priority traffic are connected). If we have both high and low state
for the cross-connections along with the route simultaneously, we
could have a misconnection. If we have only high and/or null states
for the cross-connections, we cannot have a misconnection. Similarly,
if we have only low and/or null state for the cross-connections, we
cannot have misconnections, either. In order to avoid misconnections,
we need a mechanism to have mutually exclusive high (including null)
or low (including null) state for the cross-connections along with
the route.
We observe, however, that the use of the null state may not always be
possible in optical switches, such as MEMS switches, which do not
allow for a null state. This is because a MEMS switch changes cross-
connection by tilting a mirror. So, an input port is always
connected to one of the output ports. This results in the same
situation as described in Section 4.3. A possible solution to this
for the case of LSPs with multiple priorities is explained below.
The applicability of this solution to the restoration case (or the
development of other solutions to address this problem in the
restoration case) requires further study.
6. Possible Solutions to Handle Misconnections
In order to have mutually exclusive high (including null) or low
(including null) state for the cross-connections along the route, one
may use a two-way activation approach. A Path message for the high
priority LSP activation is used to make the cross-connection state
æænullÆÆ while a Resv message for the high priority activation is used
to make the cross-connection state ææhighÆÆ.
In order to distinguish the refresh message from the activation one
for high priority traffic, we can use the Admin Status object.
Another option is to use the Protection object in the Resv message.
Finally, to solve the possible misconnection problem in optical
switches that do not allow for a null state, the source node must
wait for the high-priority LSP to be fully established before sending
out data on it. In other words, the initiator/ingress node sends out
data after receiving the RESV message for activation. For triggering
the terminator/egress node to send out data, a ResvConf message
should be sent from the initiator/ingress, and received by the
terminator/egress, before it begins transmitting data on the high-
priority LSP.
7. Conclusions
This document provided an initial discussion of misconnection
scenarios in GMPLS networks, analyzes some common scenarios, outlines
Shiomoto/Sharma/Suemura Expires December 2004 9
Analysis of Misconnection Scenarios June 2004
in GMPLS Networks
some common causes of these, and then posits some alternative ways of
handling misconnections.
8. Security Considerations
This document does not introduce any new security considerations in
the protocols considered herein.
9. References
9.1. Normative References
[1] RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] L. Berger (Ed.), "Generalize Multi-Protocol Label Switching
(GMPLS) Signaling Resource Reservation Protocol-Traffic
Engineering Extensions" RFC 3473, January 2003.
9.2. Informative References
[3] D. Papadimitriou, et al, "Analysis of Generalized Multi-Protocol
Label Switching-based Recovery Mechanisms", Internet Draft, Work
in Progress, draft-ietf-ccamp-gmpls-recovery-analysis-03.txt,
April 2003.
[4] J. P. Lang, D. Papadimitriou, Y. Rekhter (Eds.), "RSVP-TE
Extensions in Support of End-to-End GMPLS-Based Recovery",
Internet Draft, Work in Progress, draft-ietf-ccamp-gmpls-
recovery-e2e-signaling-02.txt, May 2003.
[5] A. Farrel, "Multi-protocol Label Switching Pre-emption" Internet
Draft, Work in Progress, draft-farrel-mpls-preemption-01.txt,
April 2004
10. Author's Addresses
Kohei Shiomoto Vishal Sharma
NTT Corporation Metanoia, Inc.
9-11 Midori-Cho 3-Chome 888 Villa St., Suite 200B
Musashino-Shi, Tokyo 180-8585, Japan Mountain View, CA 94041, USA
Phone: +81 (422) 59 4402 Phone: +1 408 530 8313
Email: Shiomoto.Kohei@lab.ntt.co.jp Email: v.sharma@ieee.org
Yoshihiko Suemura
NEC Corporation
1753, Shimonumabe, Nakahara-ku
Kawasaki 211-8666, Japan
Phone: +81 44 396 2804
Email: y-suemura@bp.jp.nec.com
Shiomoto/Sharma/Suemura Expires December 2004 10
Analysis of Misconnection Scenarios June 2004
in GMPLS Networks
11. Intellectual Property Considerations
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.
11.1. IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
12. Full Copyright Statement
"Copyright (C) The Internet Society (2004). 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 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."
Shiomoto/Sharma/Suemura Expires December 2004 11
| PAFTECH AB 2003-2026 | 2026-04-23 12:32:24 |