Subject: Path refresh message

From: Jie Zou <[email-masked]>
Date: Wed, 12 Jul 2000 15:04:49 -0400

Hello everyone,

I have a question about the refresh messge:

In the draft-ietf-mpls-lsp-tunnel-06.txt, section 4.2.4

"The LABEL_REQUEST SHOULD be stored in the Path State Block, so that
   Path refresh messages will also contain the LABEL_REQUEST object."

what is the format of Path refresh message ?

Thanks 

---------------------------------------------------------------------
Jie Zou		MPLS Consortium		IOL, UNH	(603)862-4212
---------------------------------------------------------------------

---

From: David Charlap <[email-masked]>
Date: Wed, 12 Jul 2000 15:17:30 -0400

> what is the format of Path refresh message ?

Identical to a Path message.

A received Path message is treated as a refresh when the information it
contains is identical to the stored path state for a session/sender.

-- David

---

From: Jie Zou <[email-masked]>
Date: Wed, 12 Jul 2000 16:46:24 -0400

Hi David,

Thanks for your answer.

I have another two questions:

1. In draft-ietf-mpls-rsvp-lsp-tunnel-06.txt, section 4.2.4

"The LABEL_REQUEST object SHOULD be stored in the Path State Block,..."

My question is if the LRO be stored in ingress node and egress node?

2. In draft-ietf-mpls-rsvp-lsp-tunnel-06.txt, section 4.2.5

"if a router has a neighbor that is known to not be RSVP capable, the
router MUST NOT advertise the LABEL_REQUEST object when sending messages
that pass through the non-RSVP routers."

How does the router knows the neighber is not RSVP capable?

Thanks

Sincerely,

---

From: David Charlap <[email-masked]>
Date: Wed, 12 Jul 2000 17:02:14 -0400

> My question is if the LRO be stored in ingress node and egress node?

An incoming LRO object is stored so that it knows what range to choose a
label from when sending a Resv to a phop node.  (And so it can detech a
change in the LR object)  For this reason, the egress node should store
it (since it is generating a Label object to send back and needs to know
the appropriate range).  The ingress node doesn't receieve anything, and
will not be generating any Resv messages, so there's nothing to store
here.

> router MUST NOT advertise the LABEL_REQUEST object when sending
> messages that pass through the non-RSVP routers."
> 

It can tell if its PHOP is not RSVP capable by comparing TTL values.

RSVP messages have a TTL field that is normally set to match the IP TTL
field.  If the message passes through a non-RSVP router, the IP TTL is
decremented and the RSVP TTL is not.  When an RSVP router receives a
message where the two don't match, it knows that there is at least one
non-RSVP router between itself and the next/previous hop that sent the
message.

I don't think you can determine this without first receieving an RSVP
message from a neighbor.

-- David

---

From: Arthi Ayyangar <[email-masked]>
Date: Wed, 12 Jul 2000 18:41:54 -0400 (EDT)

Your reasoning makes sense,
But the draft says:

"The LABEL_REQUEST object SHOULD be stored in the Path State
 Block,...so that Path refresh messages will also contain the
LABEL_REQUEST object". 

isn't that a little misleading?

Thanks,
-arthi

---

From: David Charlap <[email-masked]>
Date: Wed, 12 Jul 2000 19:27:15 -0400

> isn't that a little misleading?

Sorry.  My mistake.  The section you quoted is referring to outgoing LR
objects.  They should be stored so that refreshes all get the same kind
of LR object, with the same label-ranges.

the reason it says SHOULD instead of MUST is that your implementation
may be able to identically regenerate the object for each refresh.  In
which case, storage is unnecessary.  The overall goal is to make sure
the LR object is sent with every refresh and that it does not change.

If your implementation can not regenerate the object identically for
each refresh, then it must store the one it sent out, so that every
refresh contains an identical LR object.

When deciding who should store this, obviously it would be everybody
except the egress node.  The egress doesn't send a Path message to
anybody, so doesn't have an outgoing LR object to store.

What I described (quote below) is referring to incoming LR objects, not
outgoing.

Note that an incoming LR object may not be the same as the LR object you
send out.  There are three different kinds of LR objects (no range, ATM
range, Frame Relay range), and two of them (ATM and FR) have variable
parameters.  The LR you get in describes the label range of the
interface the Path message came from, while the LR you send out will
describe the label range of the interface you are sending your Path
message out on.  You do not want to send out one that describes some
other router's interface, because it may lead to the nhop generating a
label value that you can not use.

>> An incoming LRO object is stored so that it knows what range to
>> choose a label from when sending a Resv to a phop node.  (And so it
>> can detech a change in the LR object)  For this reason, the egress
>> node should store it (since it is generating a Label object to send
>> back and needs to know the appropriate range).  The ingress node
>> doesn't receieve anything, and will not be generating any Resv
>> messages, so there's nothing to store here.

In superbrief summary:

1. You should store outgoing label request objects so that Path
   refreshes will all contain identical LR objects.

1a. Since the egress node doesn't send out any Path messages, it
    obviously doesn't have to store an outgoing LR object.

2. You must store incoming label request objects so that you know what
   label range your phop can accept - this way you can pick a label that
   it can use.

2a. Since the ingress node doesn't receive any Path messages, it
    obviously doesn't have to store an incoming LR object.

I hope this is a bit clearer.

-- David

---

From: Jie Zou <[email-masked]>
Date: Thu, 13 Jul 2000 10:19:47 -0400

David,

I have another two refresh question:

In RFC 2205, section 2.3

1. "When the received state differs from the stored state, the stored
state is updated.  If this update results in modification of state
to be forwarded in refresh messages, these refresh messages must
be generated and forwarded immediately, so that state changes can
be propagated end-to-end without delay."

Seemly, refresh message can be different with the Path message sent
before. In my opinion, it should be a new Path message and we don't need 
to change the state(just store it).

2. Is there some standards for the refresh timeout period like 5 ms,
etc?

Sincerely,

---

From: David Charlap <[email-masked]>
Date: Thu, 13 Jul 2000 10:37:54 -0400

Jie Zou wrote:
> before. In my opinion, it should be a new Path message and we don't
> need to change the state(just store it).

It depends on what differs.

If the SESSION and SENDER objects are different, then the message is
signalling a different path.

If the SESSION and SENDER objects match those for an existing path, then
the message serves to update that path.  Either a refresh (if everything
matches) or an update (if something changed).

> 2. Is there some standards for the refresh timeout period like 5 ms,

The only reference I know of is in RSVP 2205, section 3.7.

The author suggests a refresh period of 30 seconds between outgoing
refreshes.  He also suggests that incoming messages should expire if
three refresh intervals (based on the TIME_VALUES of the last incoming
message) pass without a refresh.

He also says that these values should be configurable, because some
networks will prefer other values.

-- David

---

From: Ping Pan <[email-masked]>
Date: Thu, 13 Jul 2000 10:12:31 -0400

> anybody, so doesn't have an outgoing LR object to store.

BTW, I guess, another reason for "SHOULD" instead of "MUST" is that the
upstream nodes can use "bundling" and "message-id" mechanisms to refresh
neighbors. In which case, all the objects defined in a PATH message
(including LABLE_REQUEST) can be represented in one object...

Generally, generating duplicated individual messages can be costly at
routers.

The bundling stuff is at
http://search.ietf.org/internet-drafts/draft-ietf-rsvp-refresh-reduct-05.txt. 

- Ping

---

From: Jie Zou <[email-masked]>
Date: Thu, 13 Jul 2000 13:16:13 -0400

David,

I have a question about the layer 3 protocols:

How many kind of layer 3 protocols exist now?(like IP, ARP, etc.)

Sincerely,

---

From: David Charlap <[email-masked]>
Date: Thu, 13 Jul 2000 14:57:45 -0400

> How many kind of layer 3 protocols exist now?(like IP, ARP, etc.)

AFAIK, MPLS is only has specs for use with IP.

As for the number of protocols that exist without respect to MPLS, there
are more than I care to think about.  But that's beyond the scope of
this mailing list.

-- David