[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft response to OIF on 1:n protection
Hi,
Thanks to those who have sent me off-list comments.
Here is a draft response to the OIF on 1:n protection. Please send me (or
the list) your comments.
Thanks,
Adrian
===
Dear Jim,
Thank you for your communication to CCAMP on the use of GMPLS to provide
1:n protection at the OIF UNI and the OIF E-NNI.
We are grateful for this opportunity to comment, but we note that this
type of communication requesting clarifications is better suited to a
mailing list discussion than to official communications that, by their
nature, have a slow turn-around. The appropriate place for
discussions of GMPLS protocols is the CCAMP working group
mailing list. Details of how to subscribe to the mailing list can be found
at http://www.ietf.org/html.charters/ccamp-charter.html
Future updates to OIF UNI and E-NNI signaling may include a feature
for 1:N connection protection. The attached document presents
requirements for these features. Recently a review was completed
of RFCs 4426, 4427 and 4428 and IETF drafts that may be able to
implement this function (including draft-ietf-ccamp-gmpls-recovery-
e2e-signaling-03 and draft-ietf-ccamp-gmpls-segment-recovery-02).
It appears that the abstract messages from RFC 4426 provide much
of this functionality, however several questions resulted from this
review. OIF would appreciate review and comments from IETF
CCAMP on the following items.
1.) OIF would appreciate knowing if there are protocol features in
other IETF documents relevant to 1:N protection .
We would like to suggest that, in order to utilize advanced features of
the GMPLS control plane protocol, engineers should be familiar with
the full set of GMPLS RFCs and Internet-Drafts. These are listed on
the CCAMP charter page and can be downloaded free of charge by
clicking on the links.
Although not all of this work is directly related to protection and
restoration, it should be noted that any protocol aspect present for a
working path may also be required for a protection path. Protocol
engineers must, therefore, be familiar with the details of the protocol
before attempting to provide advanced functions like protection.
2.) RFC 4426 section 2.5.2 says "it MAY be possible for the LSPs
on the working link to be mapped to the protection link without
re-signaling each individual LSP" and "it MAY be possible to change
the component links without needing to re-signal each individual LSP".
OIF would like to know what signaling messages and objects can be
used to accomplish this.
Your question is confusing in the light of the referenced section.
The section describes the messages required to achieve span protection.
Clearly, if a span is protected, then all LSPs carried over that span
may be transparently protected. This is how normal link protection
operates and there is nothing clever going on.
Recall that section 2.5.2 is a subsection of section 2, and this is
entirely dedicated to span protection.
Further, if the bundling example is followed, the referenced RFC
(RFC4201) explains the signaling necessary to achieve bundling.
You may find it easier to consider this as a layering architecture. The
span (link) that is protected is a lower layer commodity and its
protection may be, therefore, transparent to the higher layer.
If you have a specific question we would be happy to answer.
3.) It is suggested that the Failure Indication Message (or
equivalent) from RFC 4426 can be triggered not only from a
failure but also a command from a management system.
You have not asked a specific question here so it is hard to give any
answer except for "yes".
Management systems are usually regarded as supreme. A management
system can instruct an implementation to do anything, and this may be
useful for forced or controlled switch-over. You may want to refer to
RFC4427 section 4.13.
4.) A goal of the 1:N protection is to use a bulk notification and
recovery procedure, based on RFC 4427 section 4.15. However, that RFC
states the corresponding recovery switching actions are performed at
the LSP level. It would be useful to know if bulk processing could be
applied to recovery of individual connection segments on the failed span,
not entire LSPs.
We do not understand your question. Each LSP has its own entry in the
switching matrix. Any switching recovery action that is required can
only be applied to this individual entry. Implementations may have some
optimisations (such as back-up, pre-programmed matrices, or magic matrix
re-program commands), but this is clearly out of scope of a control
plane specification.
Please note that recovery switching actions are not signaling actions.
We are also confused as to the meaning of "It would be useful to know if
bulk processing could be applied to recovery of individual connection
segments on the failed span, not entire LSPs." To process it further, we
probably need to deconstruct the term Connection Segment. As you may be
aware, the term 'connection segment' is not widely used in the ASON
Recommendations and does not find a definition there. The reference from
G.8081 is to an ATM forum document.
We assume that you are concerned to provide end-to-end data transfer.
Presumably you are interested in a variety of symmetrical cases such as
client-layer connectivity, UNI-C to UNI-C connectivity, UNI-N to UNI-N
connectivity, or UNI-N/E-NNI to E-NNI/UNI-N connectivity. The path
between these points is an LSP (it may be a hierarchical LSP through which
other LSPs are tunneled) and it is this path that you wish to protect.
Whether you perform span, segment, or end-to-end protection, you are still
protecting the LSP.
5.) RFC 4426 refers to three abstract messages involved in the
reversion sequence:
- A Bridge and Switch Request message from the source node after it
has bridged traffic back to both working and protection links.
- A Bridge and Switch Response message from the destination node after
it has bridged traffic back to both working and protection links and
changed its selector to the working link.
- A Bridge and Switch Completed message from the source node after it
has changed its selector to the working link and stopped sending traffic
on the protection link (so the destination can stop transmitting on
protection).
Since RFC 4426 covers these Bridge and Switch messages briefly, more
details should be specified on the operation and behavior in this
reversion process.
If you have specific questions, we would be happy to answer them. If you
believe that additional documentation is required, we would welcome your
contributions as an Internet-Draft.
Further, it would be helpful to understand why the actions are
performed by source and destination nodes rather than master and
slave nodes. It may be appropriate to reuse the master/slave roles
in the reversion process just as is done in the switchover process.
There is a distinction between the node that invokes a switchover
process (the master) and a node that performs the process. For
example, a Bridge and Switch Request message is sent by the source
node after it has bridged traffic back to both working and protection
links simply because the source node has performed the bridging and
is the only node that can know this fact.
In addition, RFC 4426 does not include an abstract message similar to
the Failure Indication Message to request the beginning of the reversion
procedure. It may be beneficial to include a message from the slave
device to initiate reversion, just as there is a Failure Indication
Message
to initiate switchover. (RFC 4426 states that the Failure Indication
Message may not be needed when the transport plane technology
itself provides such a notification. The same may apply when a failure
is cleared; however, there should still be an optional message to
trigger the reversion process.)
Reversion is described as an administrative procedure quite
deliberately. In our view it should not be a rapid response to a
specific situation triggered through the control plane by the 'master',
but should be a considered operation under the control of administrative
policy. The trigger is, therefore, outside the scope of the control plane.
This is in section 4.13 of RFC4427.
We hope this answers your questions, and we would be happy to enter into
further dialog on these topics.
Best regards,
Adrian Farrel and Deborah Brungard
CCAMP co-chairs