[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ... generalized-signaling-06
All,
I agree with John that the set up of the working and protection connections will
be done by means of the set up of two normal connections with the constraint
that those have to be diverse routed.
The role these two diverse routed connections play has only relevance at the
head and tail ends of the protected domain; not at any intermediate point along
the connections.
As I indicated in my presentation on Wednesday evening, connection set up has
multiple phases:
- connection bearer set up
- connection monitoring set up
- connection protection set up.
The latter one refers to the set up of the head/tail end connection functions
which include the bridges and selectors.
Note that I ignore for this moment the Dual Node Interconnect (DNI)
cases (see G.842) in which some intermediate nodes do have to know
about protection.
In section 3.2 of SG15 contribution D.301
ftp://sg15opticalt:otxchange@ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/ccamp/301_ww2.pdf
you find a high level overview of linear protection switching related management
parameters:
- Architecture Type (1+1, 1:n, ..)
- Switching Type (uni-directional, bi-directional)
- Operation Type (revertive, non-revertive)
- Protection Type (trail, SNC/I, SNC/N, SNC/S)
- Extra Traffic
- SFPriority, SDPriority
- Wait To Restore time
- Hold Off time
Note - the shared protection ring (MS Spring/BLSR and in future
OCH SPRing and ODUk SPRing) (will) have their own set of parameters.
When a call controller receives a request for a connection, it may decide that
it must create a protected connection to compy with the QoS parameters
associated with the call. The call controller then issues two connection
requests to a connection controller, with the constraint to diverse route the
two connections between the head end and tail end of the protected domain.
At this point we have to differentiate between native connection requests and
client connection requests. For the case there is a native connection request,
the protection will be of the SubNetwork Connection (SNC) type. For the case
there is a client connection request, the protection type may be of the SNC
type, or may be of the trail protection type.
Example 1: If a VC-4 call is to be supported by means of a protected
VC-4 connection, then VC-4 SNC protection will have to be deployed.
Example 2: If a STM-16 call is to be supported by means of a
protected ODU1 connection then there is a choice to use either ODU1
trail protection or ODU1 SNC protection.
Instead that the network call controller decides that a call is to be supported
by a protected connection, the user may decide such and request for two diverse
routed connections. The head/tail ends are then within the user domain.
Example 3: If a user wants a protected STM-16 connection between
e.g. two of its SDH equipment, it will set up a STM-16 MS trail
protected port in its own equipment and request two diverse routed
connections from the network.
In addition to the above two cases, there can be a 3rd hybrid case; i.e. one
bridge/seelctor pair is in the user domain and the other bridge/selector pair is
in the network domain.
When SNC protection is applicable, the fabrics will contain the protection
switch processes. Two (case of 1+1, 1:1) regular connections between the
first/last fabric in the protected domain are to be set up. Depending on the
protection type, either no monitors have to be activated (SNC/I), or non
intrusive monitors (SNC/N) have to be activated, or tandem connection monitoring
functions have to be activated (SNC/S).
When trail protection is applicable, the ports (not the fabrics) will contain
the protection switch processes. Two (case of 1+1, 1:1) regular connections have
to be set up between the working interface points of the protected ports and
between the protection interface points of the protected ports. The ports
include already the monitoring functionalities, so no specific action for
monitoring selection is required in this case.
The connection set up process must take care to provide the monitors in either
case with the correct parameter values. Parameters are associated with the
following monitoring processes: trace identifier, error detection, alarm
reporting modes (TPmode, ARCmode), TCM level.
With the connection and monitoring functions being set up, the protection
processes at each endpoint can now be configured. I.e. the set of protection
parameters listed at the begin of this email have to get values assigned.
Note - As the connection protection set up hasn't been architected
yet in ASON, it is undecided if the call controller or the
connection controllers will be responsible for the head/tail end
set up.
For the case the connections have to pass multiple subnetworks or routing
domains, the first and last subnetwork/routing domain may have a hybrid casen
(including one portected domain end point), whereas any intermediate
subnetwork/routing area has the case of two diverse routed connections (and no
protected domain endpoints).
Up to so far.
Regards,
Maarten
PS. I hadn't seen "primary" before as an indication of connection set up. It
seems unnecessary to add this adjective if it isn't used when setting up an
unprotected connection.
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:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard