Nurit Sprecher | 3 Aug 13:10 2003

Support of Graceful Restart for RSVP-TE

Hi all,

Is there any standard/draft describing the procedure to graceful restart of RSVP-TE in order to minimize the negative effects on MPLS traffic caused by LSR's control plane restart?

I can see that there was such a draft written by Pan. What is the status of the draft? Expired? Any progression with it?

Thanks in advance, Nurit.

RE: Support of Graceful Restart for RSVP-TE

See RFC 3473 section 9
 
JL
-----Message d'origine-----
De : Nurit Sprecher [mailto:nurit.sprecher <at> SeabridgeNetworks.com]
Envoyé : dimanche 3 août 2003 13:10
À : 'ccamp <at> ops.ietf.org'; 'mpls <at> uu.net'
Cc : Nurit Sprecher
Objet : Support of Graceful Restart for RSVP-TE

Hi all,

Is there any standard/draft describing the procedure to graceful restart of RSVP-TE in order to minimize the negative effects on MPLS traffic caused by LSR's control plane restart?

I can see that there was such a draft written by Pan. What is the status of the draft? Expired? Any progression with it?

Thanks in advance, Nurit.

Michael Mandelberg | 5 Aug 03:51 2003

Label Set question

How does the label set work with waveband labels? For the list form, are the subobjects waveband ids, or are the start and stop values listed as well? For the range form, again is it just ids? If not, then how is ordering defined to deterimine whether another band laebl is within the range?
 
Thanks
 
Michael Mandelberg
Bradford, Richard | 6 Aug 22:13 2003
Picon

Clarification request on rate fields in LMP

Some different interpretations for the various rates in LMP messages have come to my attention. These involve the Minimum Reservable Bandwidth and Maximum Reservable Bandwidth in a LinkSummary message.
One interpretation is that the Reservable Bandwidths at least should represent only the payload portion of the bandwidth. An alternate interpretation is that all these fields should include all overhead.

Let's take the case of a STM-4 Interface, which supports signalling of individual VC-4 circuits.


Position 1: Raw bandwidth should be used so the values should be:
 Minimum Reservable Bandwidth = OC-3/STM-1   (155.52 Mbps)
 Maximum Reservable Bandwidth = OC-12/STM-4  (622.08 Mbps)

Position 2: Since for SDH the TDM circuits will be signalled either as individual VC-4s or as a single VC-4-4c, therefore the values should be:

 Minimum Reservable Bandwidth = VC-4 (149.760 Mbps) 
 Maximum Reservable Bandwidth = VC-4-4c (599.040 Mbps)

Other interpretations?

The following are the values from generalized-signaling
        Signal Type   (Bit-rate)              Value (Bytes/Sec)
                                            (IEEE Floating point)
      --------------  ---------------       ---------------------
                 DS0  (0.064 Mbps)              0x45FA0000
                 DS1  (1.544 Mbps)              0x483C7A00
                  E1  (2.048 Mbps)              0x487A0000
                 DS2  (6.312 Mbps)              0x4940A080
                  E2  (8.448 Mbps)              0x4980E800
            Ethernet  (10.00 Mbps)              0x49989680
                  E3  (34.368 Mbps)             0x4A831A80
                 DS3  (44.736 Mbps)             0x4AAAA780
               STS-1  (51.84 Mbps)              0x4AC5C100
                  E4  (139.264 Mbps)            0x4B84D000
          OC-3/STM-1  (155.52 Mbps)             0x4B9450C0
         OC-12/STM-4  (622.08 Mbps)             0x4C9450C0
        OC-48/STM-16  (2488.32 Mbps)            0x4D9450C0
       OC-192/STM-64  (9953.28 Mbps)            0x4E9450C0
      OC-768/STM-256  (39813.12 Mbps)           0x4F9450C0

ramasamy ramanathan | 7 Aug 04:11 2003
Picon

clarification.

hi all,

Could anyone help me out with the following question?

For bi-directonal LSP, we specify upstream label in PATH message. For the
FORWARD direction we can specify label set or suggested label, so that
narrowing the nexthop label allocation range. thereby reducing the
probabaility of failure. For REVERSE path we don't have anything, while
sending the PATH message, we allocate a label and send it out without taking
the input from the nexthop. so the probablitiy of nextnode sending the error
message to this upstream label is more right? is there any mechanism to
avoid this?

thanks
rams.

Michael Mandelberg | 7 Aug 04:44 2003

RE: clarification.

There is the Acceptable Label Set. It can be included in the Path Err if the
Upstream Label is unacceptable.

Michael Mandelberg

-----Original Message-----
From: ramasamy ramanathan [mailto:ramsrm <at> tdd.sj.nec.com]
Sent: Wednesday, August 06, 2003 9:11 PM
To: ccamp <at> ops.ietf.org
Subject: clarification.

hi all,

Could anyone help me out with the following question?

For bi-directonal LSP, we specify upstream label in PATH message. For the
FORWARD direction we can specify label set or suggested label, so that
narrowing the nexthop label allocation range. thereby reducing the
probabaility of failure. For REVERSE path we don't have anything, while
sending the PATH message, we allocate a label and send it out without taking
the input from the nexthop. so the probablitiy of nextnode sending the error
message to this upstream label is more right? is there any mechanism to
avoid this?

thanks
rams.

Michael Mandelberg | 8 Aug 03:53 2003

Direction of LSP in ERO

Is it allowed for the different hops in the ERO to have different structure.
For example, coud one hop specify both an upstream and a dowstream label
while another specifies just a downstream label?

Thanks

Michael Mandelberg

Jonathan Lang | 8 Aug 18:20 2003

RE: Clarification request on rate fields in LMP

Richard,
The Reservable bandwidth fields should correlate with the reservable
bandwidth fields of GMPLS routing/signaling (without the notion of
priority).  I.e., the reservable bandwidth field is defined in gmpls
routing as follows: " Reservable Bandwidth per priority, which specifies
the bandwidth of an LSP that could be supported by the interface at a
given priority number."

Thanks,
Jonathan

> -----Original Message-----
> From: Bradford, Richard [mailto:rbradfor <at> cisco.com] 
> Sent: Wednesday, August 06, 2003 1:14 PM
> To: jplang <at> ieee.org
> Cc: ccamp <at> ops.ietf.org
> Subject: Clarification request on rate fields in LMP
> 
> 
> Some different interpretations for the various rates in LMP 
> messages have come to my attention. These involve the Minimum 
> Reservable Bandwidth and Maximum Reservable Bandwidth in a 
> LinkSummary message. One interpretation is that the 
> Reservable Bandwidths at least should represent only the 
> payload portion of the bandwidth. An alternate interpretation 
> is that all these fields should include all overhead.
> 
> Let's take the case of a STM-4 Interface, which supports 
> signalling of individual VC-4 circuits.
> 
> 
> Position 1: Raw bandwidth should be used so the values should be:
>  Minimum Reservable Bandwidth = OC-3/STM-1   (155.52 Mbps)
>  Maximum Reservable Bandwidth = OC-12/STM-4  (622.08 Mbps)
> 
> Position 2: Since for SDH the TDM circuits will be signalled 
> either as individual VC-4s or as a single VC-4-4c, therefore 
> the values should be:
> 
>  Minimum Reservable Bandwidth = VC-4 (149.760 Mbps)  
>  Maximum Reservable Bandwidth = VC-4-4c (599.040 Mbps)
> 
> Other interpretations?
> 
> The following are the values from generalized-signaling
> 
>         Signal Type   (Bit-rate)              Value (Bytes/Sec)
>                                             (IEEE Floating point)
>       --------------  ---------------       ---------------------
>                  DS0  (0.064 Mbps)              0x45FA0000
>                  DS1  (1.544 Mbps)              0x483C7A00
>                   E1  (2.048 Mbps)              0x487A0000
>                  DS2  (6.312 Mbps)              0x4940A080
>                   E2  (8.448 Mbps)              0x4980E800
>             Ethernet  (10.00 Mbps)              0x49989680
>                   E3  (34.368 Mbps)             0x4A831A80
>                  DS3  (44.736 Mbps)             0x4AAAA780
>                STS-1  (51.84 Mbps)              0x4AC5C100
>                   E4  (139.264 Mbps)            0x4B84D000
>           OC-3/STM-1  (155.52 Mbps)             0x4B9450C0
>          OC-12/STM-4  (622.08 Mbps)             0x4C9450C0
>         OC-48/STM-16  (2488.32 Mbps)            0x4D9450C0
>        OC-192/STM-64  (9953.28 Mbps)            0x4E9450C0
>       OC-768/STM-256  (39813.12 Mbps)           0x4F9450C0
> 

Adrian Farrel | 9 Aug 18:19 2003
Picon

Re: Direction of LSP in ERO

Yes.
The interpretation of ERO hops is 'strictly' limited to the scope of the hop. Later hops
will have no idea what happened in earlier hops. Early hops SHOULD NOT browse ahead in the
ERO.
Adrian
----- Original Message ----- 
From: "Michael Mandelberg" <mmandelberg <at> lopsys.com>
To: <ccamp <at> ops.ietf.org>
Sent: Friday, August 08, 2003 2:53 AM
Subject: Direction of LSP in ERO

> Is it allowed for the different hops in the ERO to have different structure.
> For example, coud one hop specify both an upstream and a dowstream label
> while another specifies just a downstream label?
>
> Thanks
>
> Michael Mandelberg
>
>

Ron Bonica | 13 Aug 05:13 2003
Picon

FW: Draft Minutes of ccamp wg meeting

Folks,

If nobody objects by COB Wednesday, I will post the following minutes of the
CCAMP WG

                                     Ron

>
> Chairs  	   Doc status - Kireeti presented slides (could not
> keep notes on
> all)
> ------------------------------------------------------------------
> ----------
> -----
> GMPLS signaling for SONET/SDH - RF Ed Q
> GMPLS Non-std SONET SDH features - killed
> GMPLS RSVP support for overlay model - authors to respond to list comment
> ASON requirments for signaling - one more update prior to straw
> poll WG last
> call
> Exclude routes ext to RSVP-TE - Adrian add appendices to describe usage
> Routing ext to support GMPLS - Kireeti did update, planned mtg prior to WG
> last call
> 			           - Number of docs stacked up
> based on this doc
> OSPF ext in support of GMPLS - awaiting above
> ASON routing rqmts - Design team created, members, milestones and schedule
> to be posted to list
> LMP - security section needs work
> SONET/SDH
> ??
> GMPLS recovery - Design team says ready for last call
> GMPLS MIBs waiting on MPLS MIBs (Adrian - 99% complete)
> GMPLS architecture - waiting on normative refs
> GMPLS trace in RFC ed Q
> Framework for GMPLS-based control of SONET/SDH - Informational
>
> Several individual contribs and WG docs not covered. Would like
> to progress
> the above mature docs.
>
> Alanqar	   ITU SG15 Liaisons
> --------------------------------
> * Links to liasion statements in slides
> * Focus is ASON signaling protocol and routing extensions
> * Thanks extended to chair and invited experts
> * Snapshot of approved and under development stds
>
> * Signaling updates
> 	- G.7713 terminology alignment with G.8080
> 	- support for crankback
> 	- Call/connection separation
> * Comments on G.7713 solicited
> * No need to develop alternative solution
>
> * Routing updates G.7715.1
> 	- Goal is consent in Oct 2003 Geneva
> 	- OSPF ext for ASON
> 	- Potential use of PNNI
>
> * Addressing: signaling, control and management usage important
> 	- separate address spaces for control and management
>
> * Auto discover G.7714.1
> 	- Further investigation initiated
> 	- Focus on type A (trail overhead)
>
> * Arch for discover & control plane G.disc_arch
> 	- New scope/title for G.7716
>
> * Management framework - new doc created in Chicago G.frame
> 	- Goal of consent by May 2004
>
> No questions
>
> Kireeti - ccamp needs to formal liaisons
>
> Papadimitriou draft-ietf-ccamp-gmpls-ason-reqts-01.txt
> ------------------------------------------------------
> * Presented by Jerry Ash
> * background, overview, issues presented
> * History has created need for better communication
> * Need to continue/ensure joint IETF/ITU-T working team
> * Much discussion on this draft since work has already been done in G.8080
> * Intent is to have extensions
> * Six broad areas of requirements
> 	 - Support for soft permanent connection capability
>       - Support for call and connection separation
>       - Support for call segments
>       - Support for extended restart capabilities during control plane
>         failures
>       - Support for extended label usage
>       - Support for crankback capability
>       - Support for additional error cases
> * Enssure GMPLS extensions interoperable with G.7713.2
>
> * Another iteration and then WG last call
> * Progress signaling extensions
> * Invitation for participation in routing requirements and protocol
> extensions
>
> * No questions nor discussion
> * Kireeti will float draft of liaison next week for comment
>
> Aboul-Magd	   draft-aboulmagd-ccamp-transport-lmp-01.txt
> ------------------------------------------------------
> * Could change title to "ASON discovery framework"
> * Is a terminology "decoder ring" mapping ASON <-> GMPLS LMP terminology
> 	- includes port and component link types
> * G.8080 has transport (data) and control plane discovery with separate
> addresses (draft says name space and not address?)
> * Proposed considering draft as WG document
> 	- A number of people had read this draft
> 	- not a broad consensus in support of this proposal
> * Lyndon Ong - Good doc, need to resolve decoder ring comments.
> * Jonathon Lang (Tellabs) - WG23 doc from ITU-T Chicago discusses some of
> these issues
> * Malcom Betts - Question on control/data plane addresses in ITU
> documentati
> on. IP address in header, NHOP, PHOP have transport address.  Intent is to
> clarify usage, if already done then no need to repeat.
>
> Papadimitriou Protection and Recovery update
> --------------------------------------------
> * Presented by Dimitri
> * Effort positioning, status and timing over past 1.5 years
> * Scope: protection, (pre-planned) rerouting, ??
> * Not covered: local recovery, end-to-end prot., crankback
> * Summarized comments received
> * Proposed acceptance as WG document
> 	- consensus was that this is ready
> 	- Kireeti - take to the list
> * Discuss the extra traffic concept in a list thread
> 	- Dimitri will propose text to clarify this
>
> Farrel	   draft-iwata-mpls-crankback-06.txt
> ------------------------------------------------
> * Adrian Farrel presented
> * Has been around for several years and this version is a major re-spin
> 	- May be more complex than single node/interface
> 	- Objective is to fail back to some intermediate point (e.g., region
> boundary or loose route identified node)
> 	- Requirement from ASON ITU-T
> 	- New co-author, John Drake
> * Summarize major changes in slides
> 	- long list of TLVs, but no adivce on which to include and when
> * Wanted to start thread on list re: remaining issues - some very thorny
> 	- session attribute bits (all would be used by this draft)
> 	- too many TLVs, need to confirm all are actually required
> 	- right place to handle unnumbered bundles
> 	- Is this the right approach, or should RRO be used?
> * Feedback solicited, resolve open issues
> * Add pointer from ASON signaling since it is long (different from slide
> presented)
> * Kireeti: close on issues, bounce use of final 3 bits off MPLS WG
> 	- decide on approach (TLVs vs RRO) and with new charter
> decide on WG status
> * Dimitri - What is the basic set of TLVs needed and then address larger
> scope.
> * Adrian - What is needed is implementation dependent. Need input
> from other
> service providers.
> * Kireeti: relate this to multi-area, multi-AS documents since a primary
> application is setup failures in multi-region.
> * Adrian: Need more explicity requirements from te-wg on crankback
> requirements.
>
> Kim	         draft-kim-ccamp-cc-protection-03.txt
> ---------------------------------------------------
> * Presented by Young Hwa Kim
> * Summarized survivability of control channels and neworks(from G.807)
> 	- assoc, non-assoc, quasi-assoc, in or out of fiber, SCN/ASTN
> implementation
> * Stated problem as no provision of protection features in current GMPLS
> control plane
> * Summarized requirements and functions for resilience of control plane
> 	- e.g., primary and secondary on separate fibers (shown in figure)
> * Next steps: proposed refine/complete requirements, 	protocol
> specification, WG document in 2003/2004
>
> * Aboul-Magd: Are control channels visible to LMP? Why are current control
> plane methods not sufficient? What are the deficiences?
> * Kireeti: Control plane is an IP network, not trying to redesign IP
> resiliency. Are some issues: is graceful restart sufficient? Need to
> convince WG that there is a problem to resolve. Do this on the
> mailing list.
> * Kim: Gigabit Ethernet has no protection, but SONET/SDH and Lamba network
> does.
> *  Malcom Betts - Control plane relies on IP network resiliency.
> G.8080 has
> a number of resiliency considerations listed.
>
> Rabbat	   draft-rabbat-optical-recovery-reqs-00.txt et al
> --------------------------------------------------------------
> * Summarized changes
> * Solicited feedback
> * Kireeti: Had requirements from te-wg, keep this as separate doc, start
> thread on mailing list
> * Draft stable, proposed adoption as WG draft
> * Need more discussion on WG list
>
> * soumiya-lmp-fault (not on agenda from Bonica)
> -----------------------------------------------
> * How we reduce message overhead slide
> * Alex Zinin - Q: Is flooding done reliably? A: Yes. Need to include
> acknowledgement messages when assessing complexity.
> * Adrian: arrows on lhs (signaling) indicate a pair of messages for
> signaling.
> * Kireeti: Was discussion comparing signaling message vs sending flooding
> messages. Signaling is often faster (contrary to stmt that it is slower).
> Flooding has a hold down timer aspect, but signaling is faster. Issue with
> using LSPs for flooding since they are link local - seems
> redundant with IGP
> (OSPF, IS-IS). Usurps LMP for different purpose. Important point is that
> flooding is slower, but fewer messages as compared with signaling.  Should
> discuss further on list. Concerned about resolving problem of flooding
> already solved in GP.
> * Aboul-Magd: Same comment as Kireeti. Need to synchronize signaling and
> routing. Don't understand why there is a need for this.
> * Jonathon Lang: Concern that message indicates a fiber cut and
> not messages
> for each affected LSP. A: Protection algorithms expect knowledge
> that nodes
> know this mapping at a protection point. Issue is that nodes may not know
> this mapping when multiple levels of indirection exist. Presenter
> requested
> feedback on the list.
> * Bonica: Take further discussion to the list.
>
> Shiomoto	   draft-pil-ccamp-extra-lsp-00.txt
> -----------------------------------------------
> * Presented by Shimoto
> * Brief overview of draft for shared mesh restoration
> 	- protecting LSP resource is reserved, but not cross-connected
> 	- extra class LSP can use this unused restoration capacity, which is
> preemptable when needed for restoration (expected to be rare occurence)
> 	- problems: advertise available resources, LSP indications
> and preemption
> in signaling, prevent unintended connections, also protect confidentiality
> * Discuss comments from mailing list
> 	- can do using existing priority mechanisms where extra
> class has lower
> holding priority than restoration LSP
> 	- complexity
> 	- soft preemption (not addressed in this draft)
> * Solicit comments/feedback
> * Proposed accepting this for ccamp wg
> * Dimitri: Question re: soft preemption as document or charter? A: Propose
> adding to charter.
> * JP Vasseur: Elaborate on soft preemption. A: Need to describe concept in
> this draft. Q: Are you aware of draft on soft preemption? A: No.
> Q: What is
> to be done with existing mechanisms?
> * Kireeti: Can be achieved with current mechanisms. Discuss on list.
> Proposed action was for Dimitri/JP Vasseur to describe on list
> how this can
> be done using existing mechanisms and Shiomoto to identify what
> is missing.
>
> Papadimitriou draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
> -----------------------------------------------------------
> * Presented by Deborah Brungard
> * Address requirements in GMPLS ASON presented earlier
> * Backward/forward compatible with GMPLS
> * Agnostic to network UNI implementation
> * Call/connection separation objects simply forwarded and not processed
> * Described proposed mechanism for call/connection separation in detail
> * Summarized other additional ASON functionalities
> * Next version - add crankback signaling and call segments
> * Solicting feedback
> * Lyndon Ong: Requesting interpretation of "backward compatibility" 7713.2
> interpretation is to carry an object if is not understood.
> * Kireeti: Need liaison to ITU-T with comments on 7713, 7713.2, and ITU-T
> liaisons and then decide how to progress this document.
>
> Ali draft-zamfir-explicit-resource-control-bundle-01.txt
> --------------------------------------------------------
> * Presented by Zafar Ali
> * Explicit Resrouce Control and Recording
> 	- Unbundled or bundled TE link type
> 	- Focus is case where component interface cannot be
> inferred from label
> value
> * Current spec supports unbundled case for LSP splicing uni- and
> bi-directional
> * Can support bundled case by specifying component ID for LSP splicing
> * Cannot support bundled case for LSP splicing when forward and backward
> component IDs are different in bi-directional
> * Propose optional interface identifier ERO subobject to address this case
> * RRO with label recording
> 	- could use to signal label values used within the bundle
> 	- cannot currently identify component interface used withing bundle
> 	- proposed solution is interface identifier RRO subobject,
> similar to above
> * Propose accepting this as WG doc
> * Kireeti: Missing element in taxonomy (matrix) of these approaches not
> sufficient for WG adoption. Understand RRO case. What is
> motivation for ERO?
> A: Could have case where component links are different where upstream and
> downstream differ. Bundle draft says that up- and down-stream can
> differ. Q:
> Why don't the local nodes assign this (and communicate selection
> in RRO). A:
> Consideration is on egress specification of component ID. Don't understand
> resistance.
> * Kireeti: Post rationale to the list, beyond missing support in
> taxonomy/martix for both RRO and ERO cases. If agreement, then
> can proceed.
> * Swallow: Provider feedback is to keep up- and down-stream on same fiber
> (pair).
> * Dimitri: Can provide examples for RRO, but believes there will
> be few for
> ERO. Please expand compatibility statement in the last section.
>
> Choi	         draft-choi-gmpls-resource-mapping-00.txt
> -------------------------------------------------------
> *  Resource Mapping for GMPLS with Heterogeneous Interfaces
> * Problem: Label format for optical interface defined, but
> specific mapping
> rule is not
> 	- Identify fiber, waveband, and lambda labels
> * Issue -1
> 	- Need aggregation for sharing in protection/restoration
> 	- Support mechanism similar to label stacking in electrical
> domain for
> optical interfaces
> * Issue -2
> 	- Logical resoure aggregation at switching interface -
> mapping, aggregation
> 	(examples given)
> 	- Miscellaneous other issues (unnumbered links, bundling,
> SRLG mapping,
> signaling, routing)
> * Is proposal acceptable to ccamp WG
> * Kireeti: Some routing and signaling defined in hierarchy draft. Here,
> FA-LSP adverstises aggregate into IGP. Asked presenter to state
> why this is
> needed on the mailing list.
>
> Fu		   draft-fu-ccamp-traceroute-00.txt
> -----------------------------------------------
> * Presented by Xiaoming Fu
> * A Proposal for Generic Traceroute Over Tunnels
> * A few issues with current GTTP draft
> 	- each hop supports GTTP
> 	- UDP issues: ports could be blocked by some ISPs, TTL=1,
> msg size>MTU
> 	- Reverse trace may not traverse same tunnel
> * Summarized potential solutions described in draft based on NSIS
> 	- Based on two-layer NTLP and NSLP NSIS protocol model
> 	- Can reuse TCP and SCTP to deliver trace messages (address
> firewall issue)
> 	- NSIS discovery finds next (NSLP?) hop and uses
> traditional traceroute
> between NSIS-enabled nodes
> * Should issues & concepts be considered in traceroute/GTTP design
> * Bonica (as individual contributor): Q: Does probe sent to destination
> visit intermediate nodes forward or backward? A: Still investigating. Q:
> Would have to use alert? A: No, signaling can used without routing alert.
> Should discovery of next hop be separate from signaling. Q: Is
> trace control
> or data plane? A: NSIS direction is discovering data path. Q: Will
> intermediate routers pass w/o change? A: Yes, traditional traceroute does
> this.
>
> Chairs	   Wrap up
> ----------------------
> * See you in Minneapolis.
> * All presenters send slides to bonica and kireeti.
>
>


Gmane