RE: protection and restoration [was: Re: Moving right along ... generalized-signaling-06]

[John Drake <jdrake@calient.net>]

Maarten,

Yes

Yes

Yes.  If two GMPLS nodes are connected with a protected link across a
SONET/SDH network, then they would simply take advantage of it.  Similarly,
some pre-OTN DWDM line systems provide the same protection capabilities and
again, the GMPLS nodes would simply take advantage of them.  As an aside,
it's becoming clear to me that we need another term to replace 'pre-OTN',
since 'pre-OTN' networks will continue to evolve in parallel with 'OTN'
networks.

Thanks,

John 

-----Original Message-----
From: Maarten Vissers
To: Mannie, Eric
Cc: ccamp@ops.ietf.org
Sent: 1/4/2002 7:26 AM
Subject: Re: protection and restoration [was: Re: Moving right along ...
generalized-signaling-06]

Eric,

You keep amazing me... I ask a simple technical question concerning a
requirement for fast restoration, which I would have expected a Yes/No
answer
for. I then asked as second technical question concerning the the
interpretation
of fast protection, which also could have been answered by Yes/No. Then
assuming
a Yes on the second answer I ask a third technical question on the scope
of fast
restoration, which could also be answered by Yes or No. Instead of 3
simple
Yes/No answers I received an email with several accusations :-( ... I
still hope
I will receive answers on my simple questions. Would be appreciated.

Regards,

Maarten

"Mannie, Eric" wrote:
> 
> Maarten,
> 
> This is too big this time, usually you are more subtle :-)
> 
> Last attempt to convince everybody that GMPLS is for pre-OTN only and
G.ASON
> for OTN ?
> 
> So that GMPLS becomes a secondary and temporary control plane until we
have
> a G.ASON based ITU-T control plane that will be used for everything
(and
> that we will have in several years) :-)))
> 
> I liked your speech during the IESG plenary when you said that the
"GMPLS
> work just started in CCAMP" and when you presented G.ASON as almost
> finished. From an honest perspective, it is exactly the opposite.
> 
> Since one cannot stop GMPLS, let's try to reduce the scope :-)))
> 
> You complained so many times that nobody is actively proposing GMPLS
at the
> ITU-T. If you could have spent the same energy that you are spending
here
> against GMPLS, rather proposing GMPLS at the ITU-T... The entire
community
> could have saved a lot of time and energy (or at least people on this
> mailing list :-)))
> 
> Rgds,
> 
> Eric
> 
> -----Original Message-----
> From: Maarten Vissers [mailto:mvissers@lucent.com]
> Sent: Wednesday, December 19, 2001 2:25 PM
> To: Mannie, Eric
> Cc: ccamp@ops.ietf.org
> Subject: protection and restoration [was: Re: Moving right along ...
> generalized-signaling-06]
> 
> Eric,
> 
> One of the requirements we have to meet is that traffic of user A is
not
> delivered to user B. Also during recovery from a failed connection
(either
> by
> means of protection swithcing, or restoration) we have to guarantee
that
> user A
> traffic is not delivered to user B. This adds additional requirements
to the
> operation of the 1:1/ET (with extra traffic), 1:n, 1:n/ET, etc
> architectures;
> these have a potential to temporarily connect A to B.
> 
> In protection switching this is guaranteed by means of the combination
of
> protection architecture and protection switching protocol type
(1-phase,
> 2-phase, 3-phase protocols).
> The tail end normal output #i of the protected domain will never
select from
> the
> protection connection until it is guaranteed that normal input #i at
the
> head
> end is bridged onto this protection connection. And vice versa, the
tail end
> will deselect the protection connection before the head end will put a
> different
> signal onto that protection connection.
> 
> I assume that for the case of restoration and fast restoration, the
same
> requirement is applicable. Has this requirement been considered in the
work
> on
> fast restoration?
> 
> It looks like "fast restoration" is a control plane based protection
> switching.
> Is my understanding correct?
> 
> If so, with transport plane based protection switching build into
SDH/SONET
> and
> OTN, is fast restoration being a pre-OTN feature? I assume there is no
need
> to
> replace SDH/SONET/OTN transport plane based protection switching by
control
> plane based protection switching.
> As pre-OTN (STM/OC-N or GE over WDM) doesn't have any protection
switching
> defined in the transport plane, pre-OTN has no alternative to control
plane
> based protection.
> 
> Regards,
> 
> Maarten
> 
> "Mannie, Eric" wrote:
> >
> > Hello Stephen,
> >
> > John refers to fast restoration schemes that are being studied at
the
> IETF.
> > Such schemes are widely implemented in the new classes of
optical/TDM
> > equipments.
> >
> > The wording of the text just need to use the terms "working" LSP and
> > "protecting" LSP, instead of primary and secondary. That's just an
editing
> > modification.
> >
> > The bit itself is useful to qualify the LSP being established.
> >
> > The mechanisms to be applied to this qualification will be detailed
in
> other
> > documents.
> >
> > In the mean time, I guess that this bit can be used by
implementations for
> a
> > simple restoration scheme (e.g. first establish working and
protecting
> LSPs,
> > resources of protecting LSP may be "soft reserved", i.e. for
> extra-traffic,
> > when a fault occur send an RSVP-TE rapid failure notification to the
> source,
> > send Path with bit set to "working" on protecting LSP, this kills
all LSPs
> > using these resources, when acked switch to this LSP).
> >
> > Kind regards,
> >
> > Eric
> >
> > -----Original Message-----
> > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> > Sent: Tuesday, December 18, 2001 7:38 PM
> > To: John Drake
> > Cc: Maarten Vissers; ccamp@ops.ietf.org
> > Subject: Re: Moving right along ... generalized-signaling-06
> >
> > John,
> > The problem here is that this is not compatible with transport plane
> > protection.
> > Assume you do 1:n MSP protection according to ITU Rec. G.841. The
> operation
> > of
> > the protection group is controlled by exchange of the K1, K2 bytes
in the
> > MSOH of the PROTECTION MS. If the control plane reuses the
protection MS
> at
> > for a different LSP at a time when the state of the protection group
is
> > "No Request" (assuming no extra traffic carried on the protection
section
> in
> > the
> > transport plane), this disables the protection since the endpoints
of the
> > protection group are no longer able to exchange K1, K2 over the
protection
> > channel. Even though the payload is unused and irrelevant to the
transport
> > plane at this point, the exchange of overhead is essential to proper
> > operation
> > of the protection group.
> > Regards,
> > Steve
> >
> > John Drake wrote:
> > >
> > > Steven,
> > >
> > > The basic idea is that if a connection is of type 'secondary',
then
> other
> > > LSPs of type 'primary' between the same or different
source/destination
> > > pairs MAY use its resources in intermediate nodes, until that LSP
is
> > > converted into a 'primary' with a subsequent Path/Resv flow.  At
this
> > point,
> > > other LSPs that were using its resources may get pre-empted.
Think of
> the
> > > primary/secondary mechanism as a way to ensure temporal priority
while
> > > allowing network resources to be re-used; i.e., an LSP of type
> 'secondary'
> > > is carrying no data.
> > >
> > > So in the 1:1 case the protect LSP could be established either as
a
> > primary
> > > or secondary LSP, while in the 1:N case the protect LSP would be
> > established
> > > as a secondary.
> > >
> > > Thanks,
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> > > Sent: Thursday, December 13, 2001 12:15 PM
> > > To: John Drake
> > > Cc: Maarten Vissers; ccamp@ops.ietf.org
> > > Subject: Re: Moving right along ... generalized-signaling-06
> > >
> > > John,
> > > It would seem from this standpoint, ANY transport plane protection
> > > must use "primary" for all trails. You have already made this
argument
> > > for the 1+1 case to carry the permanently bridged copy of the
payload.
> > >
> > > In 1:1 or 1:n, when protection is not being used to carry one/any
of
> > > the normal traffic signals, it may either carry a null signal (no
> bridge)
> > > or transport plane extra traffic. Even if the transport plane has
only
> > > a null signal on protection, the control plane cannot itself place
extra
> > > traffic on any portion of the end-to-end protection channel as
this is
> > > where the APS protocol is carried to coordinate the 1:1 or 1:n
> protection.
> > > The protection channel overhead is chosen to carry the APS since
it is
> > > necessary to exchange APS bytes to complete a switch when working
> channels
> > > are failed. If the protection channel has failed and APS cannot be
> > > exchanged,
> > > normal traffic signals will not be selected from protection.
> > > Regards,
> > > Steve
> > >
> > > John Drake wrote:
> > > >
> > > > Maarten,
> > > >
> > > > That's fine, however it's beside the point.  The semantics of
> > > > Primary/Secondary refer to the control plane and whether the
node
> > > > establishing a given LSP is planning to use it at the time it's
> > > established
> > > > or at a later time.  As I indicated in an earlier note, 1+1
transport
> > > plane
> > > > protection would be accomplished in the control plane by
establishing
> > two
> > > > LSPs of type Primary.  The control plane really doesn't care
which LSP
> > the
> > > > transport plane is using as Working and which as Protect,
although
> that
> > > > information is available to the control plane at the LSP
endpoints.
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > > -----Original Message-----
> > > > From: Maarten Vissers [mailto:mvissers@lucent.com]
> > > > Sent: Thursday, December 13, 2001 12:15 AM
> > > > To: ccamp@ops.ietf.org
> > > > Subject: Re: Moving right along ... generalized-signaling-06
> > > >
> > > > There exist well defined protection terminology in ITU-T for the
> > transport
> > > > plane. "Working" and "Protection" are being used and not
> > > primary/secondary.
> > > > E.g.
> > > > a 1+1 architecture has one working connection, one protection
> connection
> > > and
> > > > a
> > > > permanent bridge.
> > > >
> > > > Besides working/protection indication for the transport entity,
there
> is
> > > > - "active" and "standby" to indicate if the signal is selected
from
> the
> > > > working
> > > > or protection transport entity; i.e. if selector selects from
working,
> > the
> > > > working is active and protection is standby, if the selector
selects
> > from
> > > > protection the working is standby and the protection is active.
> > > > - "normal" and "extra traffic" signal. The normal signal is
protected.
> > > >
> > > > Regards,
> > > >
> > > > Maarten
> > > >
> > > > neil.2.harrison@bt.com wrote:
> > > > >
> > > > > Jonathan....review the text below....I think the problem is
1:1.
> > > > >
> > > > > neil
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jonathan Lang [mailto:jplang@calient.net]
> > > > > > Sent: 12 December 2001 17:46
> > > > > > To: 'Ben Mack-Crane'; John Drake
> > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org
> > > > > > Subject: RE: Moving right along ... generalized-signaling-06
> > > > > >
> > > > > >
> > > > > > Ben,
> > > > > >   Please see inline.
> > > > > >
> > > > > > Thanks,
> > > > > > Jonathan
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com]
> > > > > > > Sent: Wednesday, December 12, 2001 8:56 AM
> > > > > > > To: John Drake
> > > > > > > Cc: Lou Berger; Kireeti Kompella; ccamp@ops.ietf.org
> > > > > > > Subject: Re: Moving right along ...
generalized-signaling-06
> > > > > > >
> > > > > > >
> > > > > > > See comment below.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ben
> > > > > > >
> > > > > > > John Drake wrote:
> > > > > > > >
> > > > > > > > Snipped
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Ben Mack-Crane [mailto:Ben.Mack-Crane@tellabs.com]
> > > > > > > > Sent: Tuesday, December 11, 2001 6:38 AM
> > > > > > > > To: Lou Berger
> > > > > > > > Cc: Kireeti Kompella; ccamp@ops.ietf.org
> > > > > > > > Subject: Re: Moving right along ...
generalized-signaling-06
> > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >7) In Protection Information it states "The resources
> > > > > > > allocated for a
> > > > > > > > > >    secondary LSP MAY be used by other LSPs until the
> > > > > > > primary LSP fails
> > > > > > > > > >    over to the secondary LSP."  This may not always
be
> > > > > > > the case.  An
> > > > > > > > > >    explicit flag indicating whether or not extra
> > > > > > > traffic may use the
> > > > > > > > > >    secondary path resources is needed.
> > > > > > > > >
> > > > > > > > > ??? This is the purpose of this bit.
> > > > > > > >
> > > > > > > > This is not clear from the definition.  The bit is
defined
> > > > > > > as indicating
> > > > > > > > the LSP is a secondary (or protecting) LSP and in 1+1
> > > > > > protection the
> > > > > > > > secondary LSP may not be used for extra traffic.
> > > > > > > >
> > > > > > > > Perhaps the problem here is that protection features are
> > > > > > > being defined
> > > > > > > > before the protection framework and requirements are
> > > > > > done.  Is this
> > > > > > > > presupposing some particular outcome of the recovery
work in
> > CAMP?
> > > > > > > >
> > > > > > > > JD:  I think the definition of the bit is fine.  For
both
> > > > > > > 1+1 and 1:1
> > > > > > > > protection, there would be a pair of Primary LSPs
between
> > > > > > the source
> > > > > > > > and destination, rather than a Primary and a Secondary.
> > > > > > >
> > > > > > > This is an unusual use of terms.  I have never encountered
a
> case
> > > > > > > where both the working and recovery paths are call
"primary."
> > > > > > >
> > > > > > > This is not consistent with either
draft-mpls-recovery-framework
> > > > > > > or with draft-lang-ccamp-recovery.  I think this is a sign
that
> > the
> > > > > > > protection work is immature and not ready for progressing
to
> RFC.
> > > > > > >
> > > > > > For 1+1 path protection, both working/recovery paths are
> > > > > > carrying user data
> > > > > > traffic and it is an endpoint decision as to which path is
> > > > > > actually the
> > > > > > working/recovery path.  At a transit node, both paths need
to
> > > > > > be treated as
> > > > > > primary, as the resources are currently being used and
> > > > > > obviously can't be
> > > > > > used for Extra Traffic.
> > > > > >
 <<Card for Maarten Vissers>>