subscriber awareness project proposal
|
Ed Warnicke (eaw) <eaw@...>
Alon,
toggle quoted message
Show quoted text
Could you link to the proposal on the project proposals page?
Ed On Apr 24, 2014, at 12:12 PM, Alon Bernstein (alonb) <alonb@...> wrote:
|
|
|
|
Alon Bernstein (alonb) <alonb@...>
Name Subscriber awareness Repo Name Subscriber awareness Description Opendaylight is flow aware and device aware but not subscriber aware. This project proposal is a simple framework for a database that helps associate subscribers to services, flows and devices A couple of examples for applications that can use subscriber awareness: 1. A wifi subscriber tracking application: wifi subscribers can be roaming across access points. Being able to track where there are is valuable for troubleshooting and service assurance. It can even provide a basic location service by tracking which access point a wifi subscriber is associated with. A policy application can use a subscriber location to apply policies based on the device the subscriber is attached to. 2. Subscriber quality tracking: when a device fails all the subscribers associated with it are immediately known. The following models show how subscribers can be associated to flows, services and devices. Note that the term subscriber is not clear – it can mean a device or a billing entity or a person etc…we propose to name it “service owners” but for the purpose of the project proposal the term subscriber might be easier.
<attached slide> A couple of implementation notes:
• No mandate on order. No change in workflows in ODL. The subscriber awareness module is a database. • “Dangling pointers” are ok. Assuming eventual consistency. No tight synchronization • The fields can be updated by applications directly or meta data from flows • A subscriber is assigned a service by an application on top of the controller • Flows are augmented to include a subscriber identification • DataChangeListener can be used to alert the sub awareness module when a flow is created for a user
The plan is to keep this to a small and well-defined project. Issues related to identity can be introduced in follow up projects.
In principal every device that has flows can use the subscriber module, however, not all devices need to.
Scope The scope of the subscriber awareness module include: • Bind flow to service • Bind service to user • Find user • Find user by flow • Find user by device
Resources Committed (developers committed to working) TBD
Initial Committers TBD
Vendor Neutral • No vendor package names in code • No vendor branding present in code or output of build Meets Board Policy (including IPR) |
|
|
|
Alon Bernstein (alonb) <alonb@...>
Name Subscriber awareness Repo Name Subscriber awareness Description Opendaylight is flow aware and device aware but not subscriber aware. This project proposal is a simple framework for a database that helps associate subscribers to services, flows and devices A couple of examples for applications that can use subscriber awareness: 1. A wifi subscriber tracking application: wifi subscribers can be roaming across access points. Being able to track where there are is valuable for troubleshooting and service assurance. It can even provide a basic location service by tracking which access point a wifi subscriber is associated with. A policy application can use a subscriber location to apply policies based on the device the subscriber is attached to. 2. Subscriber quality tracking: when a device fails all the subscribers associated with it are immediately known. The following models show how subscribers can be associated to flows, services and devices. Note that the term subscriber is not clear – it can mean a device or a billing entity or a person etc…we propose to name it “service owners” but for the purpose of the project proposal the term subscriber might be easier.
A couple of implementation notes:
• No mandate on order. No change in workflows in ODL. The subscriber awareness module is a database. • “Dangling pointers” are ok. Assuming eventual consistency. No tight synchronization • The fields can be updated by applications directly or meta data from flows • A subscriber is assigned a service by an application on top of the controller • Flows are augmented to include a subscriber identification • DataChangeListener can be used to alert the sub awareness module when a flow is created for a user
The plan is to keep this to a small and well-defined project. Issues related to identity can be introduced in follow up projects.
In principal every device that has flows can use the subscriber module, however, not all devices need to.
Scope The scope of the subscriber awareness module include: • Bind flow to service • Bind service to user • Find user • Find user by flow • Find user by device
Resources Committed (developers committed to working) TBD
Initial Committers TBD
Vendor Neutral • No vendor package names in code • No vendor branding present in code or output of build Meets Board Policy (including IPR) |
|
|
