Re: Moving right along ... generalized-signaling-06
Maarten Vissers <mvissers@lucent.com> Wed, 19 December 2001 09:14 UTC
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 19 Dec 2001 01:19:51 -0800
Message-ID: <3C205A5D.6B18F33@lucent.com>
Date: Wed, 19 Dec 2001 10:14:05 +0100
From: Maarten Vissers <mvissers@lucent.com>
Organization: Lucent Technologies
MIME-Version: 1.0
To: ccamp@ops.ietf.org
Subject: Re: Moving right along ... generalized-signaling-06
Content-Type: multipart/mixed; boundary="------------6BA58095FEA1B65CE1735158"
All, Zhi-Wei Lin wrote: > > Hi, > > I think active/standby and extra-traffic/normal-traffic are also two > separate descriptors. They are indeed separate descriptors. See e.g. draft G.gps. > Extra traffic may be carried on a standby connection (but a standby > connection does not necessarily have extra traffic on it). Correct. 1+1 prot architecture can't even support extra traffic. E.g. 1:1 and 1:n architectures can support extra traffic. As a 1:1 architecture is more complex than a 1+1 scheme, such 1:1 architecture will typically be deployed when extra traffic support is required. See for advantages/disadvantages associated with each protection architecture section 6.2 of draft G.gps: Possible advantages of the 1+1 architecture include: 1) low complexity. 2) for the case of unidirectional switching, the possibility to support dual node interconnect of protected subnetworks. Possible disadvantages of the 1+1 architecture include: 3) 100% extra capacity. Possible advantages of the 1:n, m:n, (1:1)n architecture include: 1) possibility to provide protection access; the protection transport entity/bandwidth can transport an extra traffic signal during periods the protection transport entity/bandwidth is not required to transport a normal traffic signal. 2) extra capacity restricted to 100/n % or m x 100/n % 3) for case of m:n, protection is possible for up to m faults. Possible disadvantages of the 1:n, m:n, (1:1)n architecture include: 4) complexity. 5) for case of SNC protection class, the need for additional sublayer termination functions at ingress and egress points of the protected domain on each working and protection transport entity. 6) does not support dual node interconnect of protected subnetworks. 7) n >= 2: each of the n working transport entities must be routed via different facilities and equipment to prevent the existence of common points of failure that can not be protected by the single protection transport entity in a 1:n and (1:1)n architecture. NOTE: Typically, n+1 alternative paths between two nodes in the network will not be available. As such, 1:n and (1:1)n, with n >= 2, architectures will not provide adequate protection for the n normal signals transported normally via the n working transport entities. n = 1 seems the only reasonable choice. NOTE: In ATM, protection access is not explicitly required to allow usage of the normally unused protection bandwidth; ABR and UBR traffic could use this protection bandwidth by means of a over-subscription of the bandwidth of the server signal containing the protection transport entity. The ABR/UBR higher layer control mechanism is assumed to reduce the traffic when the protection is actually used. The ingress/egress nodes of the protection domain do not have to align with ingress/egress nodes of ABR/UBR traffic. This adds flexibility to the network, and reduces complexity. > > How do we define normal traffic? Is this user traffic carried by working > path (when working is active), or also carried by recovery path (when > recovery is active)? Normal traffic signal is defined as follows (see G.gps): 3.10.1 Normal traffic signal - Traffic signal that is protected by two alternative transport entities, called working and protection entities. 3.10.2 Extra traffic signal - Traffic signal that is carried over the protection transport entity and/or bandwidth when that transport entity/bandwidth is not being used for the protection of a normal traffic signal; i.e. when protection transport entity is standby. Whenever the protection transport entity/bandwidth is required to protect or restore the normal traffic on the working entity, the extra traffic is pre-empted. Extra traffic is not protected. 3.10.3 Null signal - The null signal is indicated on the protection transport entity if it is not used to carry normal or extra traffic. The null signal can be any kind of signal that conforms to the signal structure of the specific layer and is ignored (not selected) at the tail end of the protection. > > And once you defined these, I think you still may need to specify > whether a connection is revertive or non-revertive. Revertive and non-revertive are protection "operation types". > > For example, take the case of 1+1. One operator may decide to use > non-revertive (because both paths are "equivalent") so avoid a switching > hit on the traffic (order of milliseconds?), while another operator may > decide to use revertive (because the recovery path is much longer/more > hops). Section 6.4/G.gps lists 5 cases where revertive operation may be appropriate: 1) Where parts of the protection transport entity may be taken to provide capacity to meet a more urgent need. For example, where protection transport entity can be taken out of service to release capacity for use in restoring other traffic. 2) Where the protection transport entity may be subject to frequent re-arrangement. For example, where a network has limited capacity and protection routes are frequently re-arranged to maximize network efficiency when changes occur in the network. 3) Where the protection transport entity is of significantly lower performance than the working transport entity. For example, where the protection transport entity has a worse error performance or longer delay than the working transport entity. 4) When an operator needs to know which transport entities are carrying normal traffic in order to simplify the management of the network. 5) Where dual node interconnect mechanism is applied to reliably interconnect two protected subnetworks. > Could these decisions be made per protected LSP basis? Yes. > If yes, then would tail-end need to know which mode it is operating/to > use (the intermediate nodes don't need to know this)? For the case of 1+1 architecture with "uni-directional switching" (switching type is another parameter) only the tail end needs to know the operation type. For a bi-directional connection, each tail end needs to know its operation type... in principle one direction can use non-revertive whereas the other direction can use revertive... but this is not logical, so default is to have both tail ends operating with the same operation type. For 1+1/1:n "bi-directional switching" both head end and tail ends need to know operation type, and the operation type must be the same at both ends. Intermediate nodes don't need to know about any of those protection parameters. Those protection parameters are allocated to the protection processes at the edge of the protected domain. See also figure 3 in section 3.2 in VBI contribution D.301 (SG15, Oct. 2001). Regards, Maarten > > Zhi > > Ben Mack-Crane wrote: > > > Maarten, > > > > In the work on a recovery framework for mpls (draft-ietf-mpls-recovery-frmwrk-03.txt) > > we chose "working path" and "recovery path." We used "recovery" instead of "protection" > > because it seemed a more neutral term given that we were including both protection > > switching and reroute recovery mechanisms. > > > > We did not address the state (active/standby). We use the terms "extra traffic" and > > "working traffic" (perhaps the latter could be changed to "normal traffic"). > > > > It would be useful in moving forward in CCAMP if we could try to adopt terms > > that are consistent with those in current use elsewhere. > > > > Regards, > > Ben > > > > Maarten Vissers wrote: > > > >>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. > >>>> > >>>> > >
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- Re: Moving right along ... generalized-signaling-… Dimitri Papadimitriou
- Re: Moving right along ... generalized-signaling-… Dimitri Papadimitriou
- Re: Moving right along ... generalized-signaling-… Maarten Vissers
- Re: Moving right along ... generalized-signaling-… Maarten Vissers
- RE: Moving right along ... generalized-signaling-… John Drake
- RE: Moving right along ... generalized-signaling-… Mannie, Eric
- Re: Moving right along ... generalized-signaling-… Stephen Trowbridge
- Re: Moving right along ... generalized-signaling-… Stephen Trowbridge
- Re: Moving right along ... generalized-signaling-… Zhi-Wei Lin
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- RE: Moving right along ... generalized-signaling-… John Drake
- Re: Moving right along ... generalized-signaling-… Maarten Vissers
- Re: Moving right along ... generalized-signaling-… Stephen Trowbridge
- RE: Moving right along ... generalized-signaling-… John Drake
- Re: Moving right along ... generalized-signaling-… Maarten Vissers
- Re: Moving right along ... generalized-signaling-… Lou Berger
- RE: Moving right along ... generalized-signaling-… John Drake
- RE: Moving right along ... generalized-signaling-… neil.2.harrison
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- RE: Moving right along ... generalized-signaling-… Bill Breck
- Re: Moving right along ... generalized-signaling-… Maarten Vissers
- RE: Moving right along ... generalized-signaling-… Jonathan Lang
- RE: Moving right along ... generalized-signaling-… Jonathan Lang
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- Re: Moving right along ... generalized-signaling-… Zhi-Wei Lin
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- RE: Moving right along ... generalized-signaling-… John Drake
- Re: Moving right along ... generalized-signaling-… Zhi-Wei Lin
- Re: Moving right along ... generalized-signaling-… Richard Douville
- RE: Moving right along ... generalized-signaling-… John Drake
- Re: Moving right along ... generalized-signaling-… Ben Mack-Crane
- Re: Moving right along ... generalized-signaling-… Lou Berger