AW: [ANCP] Question about the ANCP high-level architecture

["Haag, T" <Thomas.Haag at t-systems.com>]

Stefaan, Kais,

Following your discussion I think we should not split between NAS policy and AN policy. The main focus should be to have one common subscriber policy server which talks via ANCP to the clients which reside in the AN. 

There are good reasons from an operational perspective. Having street cabinet installation each AN has to be connected separately to an AN Policy server which has to aggregate and to report to the NAS policy server. I expect more delay which might cause that e.g. a port up message will arrive later than a PPP - session up will arrive at the NAS.

Also other draw backs should be taken into account. Having in mind that a AN can be split in several partitions and each partition can talk to an individual NAS. In that case an AN policy server has to manage multiple connection to multiple NAS.

Regards

Thomas


Betreff: Re: [ANCP] Question about the ANCP high-level architecture

stefaan.de_cnodder at alcatel.be wrote:

>
> Hi Kais,
>
> see below...
>
> Kais Belgaied wrote:
>
>> Folks,
>>
>> My question is regarding the following picture of the high level ANCP
>> architecture:
>>
>>
>>                                                +--------+
>>                                                | Policy |
>>                                                | Server |
>>                                                +--------+
>>                                                     |
>>                                                     |
>>   +-----+   +-----+   +--------+                 +-----+   +----------+
>>   | CPE |---| HGW |---|        |                 |     |   |          |
>>   +-----+   +-----+   | Access |   +---------+   |     |   | Regional |
>>                       |  Node  |---| Aggreg. |---| NAS |---| Network  |
>>   +-----+   +-----+   |        |   |  Node   |   |     |   |          |
>>   | CPE |---| HGW |---|        |   +---------+   |     |   |          |
>>   +-----+   +-----+   +--------+                 +-----+   +----------+
>>
>>
>> The policy server is attached to the NAS only.
>>
>> A couple of observations about the AN:
>> . it is shared between multiple HGWs that don't know/trust each other
>> . it is the first candidate for enforcing link sharing policies (e.g. 
>> bandwidth
>>  allocation) between subscribers attached to those HGWs
>>
>
> do you mean that bandwidth can be shared between 2 subscribers? This 
> can also be done by the NAS Policy server I would 


yes, that's what I mean. I understand the  information about all 
subscribers is available at the  Policy server.

> think. Note that the main focus of the WG is DSL, and sharing 
> bandwidth in DSL is rather difficult.


I'm possibly seeing more sharing in the aggregation node component than 
there actually is with DSL.
I view it as a resource shared between multiple subscribers, therefore 
the AN being the arbitrator for
accessing that resource would be a natural choice.
If in reality (and in the foreseeable future) the model for the 
aggregation node is just a collection of
independent pipes to to the NAS, then, yes the NAS is the first point 
shared access, and the policy
enforcement belongs there.

>
>> Such policy is applicable to HGWs connected to the same AN.
>> There may be other policy information still live in the NAS policy 
>> server.
>> The picture could look more like:
>>
>>                        +--------+              +--------+
>>                        |   AN   |              |  NAS   |
>>                        | Policy |              | Policy |
>>                        | Server |              | Server |
>>                        +--------+              +--------+
>>                            |                        |
>>                            |                        |
>>   +-----+   +-----+   +--------+                 +-----+   +----------+
>>   | CPE |---| HGW |---|        |                 |     |   |          |
>>   +-----+   +-----+   | Access |   +---------+   |     |   | Regional |
>>                       |  Node  |---| Aggreg. |---| NAS |---| Network  |
>>   +-----+   +-----+   |        |   |  Node   |   |     |   |          |
>>   | CPE |---| HGW |---|        |   +---------+   |     |   |          |
>>   +-----+   +-----+   +--------+                 +-----+   +----------+
>>
>> comments?
>>
>
> As mentioned during the meeting, the interaction with the policy 
> server has to be further detailed. I do not say that the above 
> architecture is invalid but I do not see how it relates to the current 
> framework of ANCP. The NAS policy server gives all subscriber 
> information to the NAS, which enforces the policies are gives them to 
> the AN via ANCP. If you have 2 policy servers, then you must also take 
> care of all possible interactions, e.g., AN policy server says that 
> the bandwidth is x Mbps while the NAS says y Mbps.


I should've clarified: the AN policy database is a subset of the whole 
policy database residing in the NAS policy server.
the AN server caches in the information relevant to subscribers 
connecting through it *only*.
and yes, that'll add a  requirement on the AN to keep the cached version 
in sync with the NAS',

>
> Maybe an Element Management system to the AN can be added because that 
> one has some interaction with ANCP.


makes sense.

    Kais.

>
> regards,
> Stefaan
>


_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp

_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp