Subject: [ANCP] About Delegated bandwidth query in draft-ietf-ancp-mc-extensions-00

From: Fortune HUANG <[email-masked]>
Date: Wed, 22 Jul 2009 10:30:50 +0800

Dear all,
 
The delegated bandwidth query request in draft-ietf-ancp-mc-extensions-00 is
only triggered by the NAS(see section 4.8). However, I think the delegated
bandwidth query request is also needed to be triggered by the AN. For
example, AN requests to reallocate the delegated bw, NAS/PS does so but the
response gets lost. In this case, the delegated bandwidth data in both sides
may be inconsistent but only the AN knows this happens. I think the
bandwidth query request triggered by the AN can be useful in this case.

Best regards,
Fortune

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Mon, 27 Jul 2009 11:23:48 +0200

Hello Fortune

On 22 Jul 2009, at 04:30, Fortune HUANG wrote:

> Dear all,
>
> The delegated bandwidth query request in draft-ietf-ancp-mc- 
> extensions-00 is only triggered by the NAS(see section 4.8).  
> However, I think the delegated bandwidth query request is also  
> needed to be triggered by the AN. For example, AN requests to  
> reallocate the delegated bw, NAS/PS does so but the response gets  
> lost.

that should not happen too often since we are assuming reliable  
transport.

>  In this case, the delegated bandwidth data in both sides may be  
> inconsistent but only the AN knows this happens. I think the  

Is this situation not already addressed via the Delegated Bandwidth  
reset procedure of section 4.10?
ie AN knows it has an invalid Delegated Bandwidth, so it triggers  
bandiwtdh delegation reset.

Francois

>
>
> Best regards,
> Fortune
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp

---

From: "Shridhar Rao (shrirao)" <[email-masked]>
Date: Mon, 27 Jul 2009 15:40:46 +0530

Hi folks,

Some of my observations:

I found that encoding of following can be made to be word aligned to
make the coding simple and consistent: 

1. Multicast-Service-Profile TLV (actually, I am referring to Single
Multicast flow field inside this TLV)

+-+-+-+-+-+-+-+-+

| Group PrefLen |

+-+-+-+-+-+-+-+-+

| Source PrefLen|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Group Prefix (multicast) (0 to 16 octets) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Prefix (unicast, SSM only) (0 to 16 octets) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

To make it word aligned, it's better to change Group Preflen and Source
PrefLen fields to 16 bits instead of 8 bits, or we can add 2 bytes of
padding immedtiately after Source PrefLen so that Group (or Source)
Prefix starts at a word aligned address (it's easier to deal with word
aligned addresses)

2. Multicast-Flow TLV

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|TLV Type = Multicast-Flow | TLV Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Addr Family | Encoding Type | Multicast Flow Source Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Multicast Flow Source Address (Ctnd) ... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Even here, we can make Addr Family and Encoding Type 16 bit fields to
have Flow Addresses start from word aligned addresses.

3. Request-Source-IP sub-TLV

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|sub-TLV Type = Request-Source-IP | Request-S-IP sub-TLV Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Addr Family | Encoding Type | Unicast Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Same comment applies to this too.

4. Command TLV

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Command Code |R O M Flags | Command Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Addr Family | Encoding Type | Multicast Flow Source Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Multicast Flow Source Address (Ctnd) ... |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Again, the same comments : make Addr Family and Encoding Type 16 bits
fields.

Thanks,

-shridhar-

---

From: Fortune HUANG <[email-masked]>
Date: Tue, 28 Jul 2009 17:20:23 +0200

Hello Francois,

As said during the ANCP session yesterday, the reset procedure can address
this situation, but the reset procedure itself is too heavy.

There reasons are as follows:

1) In the example in my previous email, there is no need for the NAS/PS to
stop admitting new requests.

2) In the example in my previous email, there is no need for the NAS/PS to
query the AN's view of the delegation when the AN triggers the query.

My proposal is to have a simple request-response query triggered by the AN.
If the NAS/PS does need to know the AN's view of the delegation, this
information can be carried in the request.

Best regards,

Fortune

  _____  

From: Francois Le Faucheur IMAP [mailto:[email-masked]] 
Sent: Monday, July 27, 2009 11:24 AM
To: Fortune HUANG
Cc: Francois Le Faucheur IMAP; [email-masked]
Subject: Re: [ANCP] About Delegated bandwidth query in
draft-ietf-ancp-mc-extensions-00

Hello Fortune

Dear all,

response gets lost.

that should not happen too often since we are assuming reliable transport.

 In this case, the delegated bandwidth data in both sides may be
inconsistent but only the AN knows this happens. I think the bandwidth query
request triggered by the AN can be useful in this case.

Is this situation not already addressed via the Delegated Bandwidth reset
procedure of section 4.10?

ie AN knows it has an invalid Delegated Bandwidth, so it triggers bandiwtdh
delegation reset.

Francois

Best regards,
Fortune

---

From: Tom Taylor <[email-masked]>
Date: Tue, 28 Jul 2009 11:37:40 -0400

I'm willing to admit that I put together the reset procedure and may have seen 
more stringent requirements than in fact are applicable.

Fortune HUANG wrote:
> ------------------------------------------------------------------------
>