Subject: [NSIS] question to the wg on make before break

From: [email-masked]
Date: Fri, 16 Apr 2004 16:08:50 +0200

Hi all,

During the early review session at the last IETF meeting, we got a question
on the support of make-before-break reservation. The concept of
make-before-break was introduced in RFC3209 (RSVP-TE) as a way to move
traffic to a new LSP before tearing down the old LSP. This essentially
requires one of two situations:
1. Pre-setup a reservation on a "future path": this requires explicit
routing capability (and a way to figure out the future path). We would like
to request the WG view on:
- whether this should be supported
- if yes, whether this is a functionality that should be supported by the
NSLP. One aspect to consider here is what make-before-break scenario you
would like to support:
      a. reserve on a diverse path between two peer QNEs: this would
require GIMPS to support explicit routing and the API to support the
request for "diverse-route-protect". Do we want this?
      b. reserve on a diverse path bypassing the peer QNE
(make-before-break in case of QNE failure): this requires a way for the QoS
NSLP to figure out a future peer QNE and a way to ask GIMPS to set up a
connection to it (API issue). Do we want this?

2. Keep the data on the old path while the reservation on the new path is
being set up: this requires route pinning but it doesn't seem to put
additional requirements on either NTLP or NSLP (only on the forwarding
function in the data plane): NSIS signalling always follows the current L3
route. However, it only helps when a better route becomes available, not
when the current one fails.

Cheers,
Sven

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Takako Sanda <[email-masked]>
Date: Mon, 19 Apr 2004 15:09:48 +0900

Hi Sven,

My opinions are in line.

> - whether this should be supported

RFC3583 ("Requirement of a QoS Solution for Mobile IP") requires
minimizing the interruption in QoS at the time of handover in Section
3.1-1. And section 3.2-1 says "The QoS mechanism for Mobile IP SHOULD take
advantage of these mobility protocols for the optimized operation."
This means that, I think, at least QoS for Mobile IP requires pre-setup
though discussion of requirements from mobility point of view may be
a bit early in this stage of NSIS WG.

> connection to it (API issue). Do we want this?

For a), I may not fully understand what diverse-route-protect means.
For b), may be yes. It will depend on what kind of mechanism is used for
pre-setup. If QNE(NSLP) can find future path and CRN earlier than NTLP,
b) will be required.

> when the current one fails.

This should be supported as "basic method" for make-before-break.
Pre-setup may be failed or may not be available. For these cases, 2)
should be supported as a backup method.

Cheers,
Takako

---

From: "Cheng Hong" <[email-masked]>
Date: Tue, 20 Apr 2004 00:14:03 +0800

Hi Sven,

My understanding is that the two cases differs on whether there is an IP
connectivity on the alternative path before the session transition (so
called break). The case 1) is when there is no such IP connectivity
available, and case 2) is when there is such IP connectivity. 

For the case 1), it would require certain assistance for the signaling, e.g.
the path "prediction", or proxy assistance, etc., to signal over the new
path. While for case 2), it is more like the multi-homed cases, and the
requirements would be similar to that.

I think both of the cases have typical usages, e.g. case 1) would be common
with the FMIP deployments, and case 2) could be a common multimode terminal
handover process. Therefore, they should all be supported by the NSIS
(NSLP+NTLP)

As for the case 1a), if I did not get it wrong, the "diverse-route-protect"
is the same requirement for the multi-home cases, and the similar what we
have discussed before.

For the case 1b), I am not very sure about the use cases. Do you mean that
the QNE could specify avoiding inclusion of another QNE on the new path to
the GMIP?

cheers

Cheng Hong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Friday, April 16, 2004 10:09 PM
> To: [email-masked]
> Cc: McDonald, Andrew; Georgios Karagiannis
> Subject: [NSIS] question to the wg on make before break
> 
> 
> Hi all,
> 
> During the early review session at the last IETF meeting, we 
> got a question on the support of make-before-break 
> reservation. The concept of make-before-break was introduced 
> in RFC3209 (RSVP-TE) as a way to move traffic to a new LSP 
> before tearing down the old LSP. This essentially requires 
> one of two situations: 1. Pre-setup a reservation on a 
> "future path": this requires explicit routing capability (and 
> a way to figure out the future path). We would like to 
> request the WG view on:
> - if yes, whether this is a functionality that should be 
> supported by the NSLP. One aspect to consider here is what 
> make-before-break scenario you would like to support:
>       a. reserve on a diverse path between two peer QNEs: 
> this would require GIMPS to support explicit routing and the 
> API to support the request for "diverse-route-protect". Do we 
> want this?
> (make-before-break in case of QNE failure): this requires a 
> way for the QoS NSLP to figure out a future peer QNE and a 
> way to ask GIMPS to set up a connection to it (API issue). Do 
> we want this?
> 
> 2. Keep the data on the old path while the reservation on the 
> new path is being set up: this requires route pinning but it 
> doesn't seem to put additional requirements on either NTLP or 
> NSLP (only on the forwarding function in the data plane): 
> NSIS signalling always follows the current L3 route. However, 
> it only helps when a better route becomes available, not when 
> the current one fails.
> 
> Cheers,
> Sven
> 
> 
>

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 19 Apr 2004 14:37:44 -0400

--On Friday, April 16, 2004 4:08 PM +0200 [email-masked] 
wrote:

> Hi all,
>
> During the early review session at the last IETF meeting, we got a
> question on the support of make-before-break reservation. The concept of
> routing capability (and a way to figure out the future path). We would
> like to request the WG view on:
I think the answer should be yes, but I don't understand the comment about 
needing explicit routing to make this work (at least as the term is used in 
the MPLS world). Could you elaborate?

> NSLP.
Hmmm, this may be another of those pesky "between the layers" things. Why 
should this have to be invented separately for QoS, NAT/Firewall, or other 
NSLPs?

> One aspect to consider here is what make-before-break scenario you
> would like to support:
Supporting disjoint path constraints, all other things being equal, is a 
good idea. In fact, it might be a good idea to think through a way to 
express a variety of constraints since disjoint path is only one of a 
number of possibilities. I do believe that disjoint path as a constraint 
does require at least route recording, and possibly explicit routing (in 
the sense of pre-computed and source routed). One thing to consider here is 
if this gets into the nether world of backing NSIS into a complete QoS 
routing protocol which will make PNNI look like a walk in the park.

> (make-before-break in case of QNE failure): this requires a way for the
> QoS NSLP to figure out a future peer QNE and a way to ask GIMPS to set up
> a connection to it (API issue). Do we want this?
>
Won't this happen correctly as a side effect of next-hop selection? If not, 
then there's something about the architecture I must misunderstand.

> when the current one fails.
Right - that's one reason I don't think we can retain the single-path model 
of routing that NSIS assumes today.

NSIS needs access to the RIBs as well as the FIBs, it seems, unless the 
routing system puts alternate path info in the FIB along with the active 
path info. Again, striking a bblance between just managing resources on the 
single best path that routing tells NSIS about and diving full depth into 
QoS routing is going to be an interesting juggling act.

Not to mention keeping C-mode and D-mode straight and having a good 
interface for D-mode that allows NSIS to express forwarding constraints to 
the routing layer...

Dave.

---

From: Marcus Brunner <[email-masked]>
Date: Thu, 22 Apr 2004 16:45:08 +0900

> - whether this should be supported

No, it should not be suported. Makes NSIS more complex. You can still 
implement make-before-break on (application-level) if you like to. So 
creating a new session before you close the old one.

Marcus

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 24 Apr 2004 14:09:14 +0200

hi dave, 
hi all, 

i have a question regarding two of your comments in your early review team
mail
http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg03809.html:

"
- Policy control may involve "envelope resource utilitzation" policy in 
addition to simple AAA. This means that hard synchronization with the AAA 
policy state and the NSLP element may be necessary.
- Is there a need for explicit teardown invoked by the AAA element?
"

could you describe what you mean with the first item? is this related to
your statement about RADIUS and QoS handling?

regarding the second item: i think there is a need for such an explicit
teardown invoked by a aaa element. if you have something like a pre-paid
card and your credits expire then it might be useful to send a message to
the initiator of the qos reservation that the reservation will experience a
teardown soon (with an indication of the reason). the aaa server would not
directly send a message to the initiator - instead network elements along
the path would provide this functionality. preemption might be another
reason for a notification sent to the initiator. in certain mobility
scenarios it might also be helpful to send a notification to the initiator.
as an example consider a mobile network which cannot support the qos
reservation anymore .

ciao
hannes

---

From: "David R. Oran" <[email-masked]>
Date: Sun, 25 Apr 2004 04:20:54 -0400

> http://www1.ietf.org/mail-archive/working-groups/nsis/current/msg03809.ht
Sure. Thanks for asking.

> "
> - Policy control may involve "envelope resource utilization" policy in
Well, RADIUS is only one of a number of possible AAA 
protocols/architectures for enforcing policy on admission control. Others 
include COPS-RSVP and DIAMETER. My comment relates to having enough state 
synchronizaton among sources/sinks, network elements, and a policy control 
element to enforce envelope utilization bounds. The policy server (I prefer 
that term in this context to AAA server since it is doing more than 
statelessly authorizing requests) knows, for any given authenticated 
source/sink of traffic in its domain of control, the aggregate of resource 
(bandwidth, public IP addresses, etc.) that source/sink is permitted and 
keeps track of admission control decisions in order to enforce that upper 
bound. From the point of view of NSIS, I believe this requires, at a 
minimum, the kind of "policy object" support found in RSVP. Beyond that, I 
believe handling pre-authorization state would be useful, as would some 
form of cut/paste and replay protection on the policy state in the 
protocol.

I know I keep hammering on this, but I believe this is *yet another* of 
these common protocol elements which reside ABOVE the transport, but BELOW 
the NLSPs.
Having different AAA and resource policy control mechanisms in the 
different NLSPs strikes me as bad in many ways - performance and 
consistency among them.

> the initiator of the qos reservation that the reservation will experience
> a teardown soon (with an indication of the reason).
Yes, I think we agree on this. The exact machinery is probably a creature 
of the AAA/policy control protocol and not NSIS itself though. I have a 
personal preference for escrow-based authorization rather than explicit 
teardown for pre-paid style applications, but there are enough other 
examples where explicit teardown is useful that the point holds.

> the aaa server would
> not directly send a message to the initiator - instead network elements
> along the path would provide this functionality.
also agree.

> preemption might be
> another reason for a notification sent to the initiator. in certain
> mobility scenarios it might also be helpful to send a notification to the
> initiator. as an example consider a mobile network which cannot support
> the qos reservation anymore .
>
Sure. I have been working on a scheme for near-optimal handling of 
preemption events which requires more protocol machinery than simple 
teardown notification but notification is needed anyway so let's start 
there.

Dave.