Subject: ASPEC and MTU

From: Yuan Gu <[email-masked]>
Date: Tue, 28 Aug 2001 16:23:04 -0400

Hello, everyone:

According to section 2.6 of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt and
RFC2210, MTU should be getten from ASPEC if Integrated Services object
is presented in Path msg.

On the other hand, ASPEC is an OPTIONAL object according to section 3.1
of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt.

My quesions are:

1. In the case of Integrated Service Tspec is presented in Path msg, is
ASPEC still OPTIONAL?
2. If the answer of above question is YES, how do we manage the Path MTU
if ASPEC is not presented in Path msg?

Thanks for your answer!

Best Regards!
Yuan Gu

---

From: David Charlap <[email-masked]>
Date: Tue, 28 Aug 2001 16:44:36 -0400

Yuan Gu wrote:
> 
> According to section 2.6 of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
> and RFC2210, MTU should be getten from ASPEC if Integrated Services
> object is presented in Path msg.

No.  ADSPEC is used by the transit routers to calculate the MTU along
the path.  It says nothing about what else should be done with this
value.

The MTU requested for the LSP is in the TSPEC object.

> On the other hand, ASPEC is an OPTIONAL object according to section
> 3.1 of draft-ietf-mpls-rsvp-lsp-tunnel-08.txt.
> 
> My quesions are:
> 
> 1. In the case of Integrated Service Tspec is presented in Path
> msg, is ASPEC still OPTIONAL?

Yes.  The choice of service (controlled-load, guaranteed, or Null) is
determined by what services are present in the Adspec object.  If it is
missing, then it is up to the implementation of the egress router to
decide.

> 2. If the answer of above question is YES, how do we manage the
> Path MTU if ASPEC is not presented in Path msg?

In this case, path MTU is not computed.  The MTU requested in the TSPEC
should be used.  If it is no good, then a router somewhere will reject
the Resv with an admission control error.

-- David

---

From: Yuan Gu <[email-masked]>
Date: Tue, 28 Aug 2001 17:16:36 -0400

David:

Could you explain detailly what's the diffrent between TSPEC MTU and ASPEC
MTU? And what's the diffrent between LSP requested MTU and Path MTU?

Best Regards!
Yuan

---

From: David Charlap <[email-masked]>
Date: Tue, 28 Aug 2001 18:15:49 -0400

Yuan Gu wrote:
> 
> Could you explain detailly what's the diffrent between TSPEC MTU
> and ASPEC MTU? And what's the diffrent between LSP requested MTU
> and Path MTU?

These are really basic questions.  You should read the IntServ RFCs more
closely.

TSPEC MTU is the MTU size in the SENDER_TSPEC object that is included in
Path messages.  It is the MTU size that the ingress router is requesting
for the LSP.

ADSPEC MTU is the MTU size in the ADSPEC object that is included in Path
messages.  It is either in the general parameters service fragment or in
the null service fragment, depending on which is used.  It is initialize
to the TSPEC MTU by the ingress router.  As the Path message propagates
through the network, the ADSPEC MTU may be reduced by routers whose MTU
values are smaller.

When the Path message finally arrives at the egress router, the MTU in
the TSPEC object (which has not changed) contains the MTU size that the
sender wants to use.  The MTU in the ADSPEC object (which was reduced by
the various transit routers) contains the path-MTU along the route that
the Path message followed.

During Resv processing, the egress router can include an MTU size in the
FLOWSPEC object.  (Zero means "don't care").  As the Resv message
propagates back to the ingress router, each transit router will compare
the MTU size of the FLOWSPEC with its own capabilities.  If the
requested MTU is beyond the router's capabilities, then it will fail the
reservation and generate an admission-control failure (delivered to the
ingress via PathErr in the case of RSVP-TE.)

If the reservation doesn't fail, then the ingress router will know the
maximum MTU value for the LSP by looking at the MTU value in the
received FLOWSPEC object.  It now has enough information to fragment
incoming IP datagrams such that they will not have to be further
fragmented by transit routers along the LSP.

-- David