[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ... generalized-signaling-06
John,
To be more generic, any technology that does not support associated
overhead (SDH/Sonet) or non-associated overhead (G.709 OCh) can use
the control plane for protection switching purposes.
In addition to the references you have provided i would like to add
the following one:
http://search.ietf.org/internet-drafts/draft-many-optical-restoration-01.txt
Cheers,
- dimitri.
John Drake wrote:
>
> Stephen,
>
> You're absolutely right if you want to use K1/K2 to signal the switchover
> from working to protect. We were planning to use the control plane
> signalling protocols, since we have to deal with more than just SONET/SDH.
> See for example:
>
> http://search.ietf.org/internet-drafts/draft-li-shared-mesh-restoration-01.t
> xt
>
> http://search.ietf.org/internet-drafts/draft-bala-protection-restoration-sig
> naling-00.txt
>
> Thanks,
>
> John
>
> -----Original Message-----
> From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> Sent: Tuesday, December 18, 2001 10:38 AM
> 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.
> > > > >
begin:vcard
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NA (NSG) - Antwerpen
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard