Ticket #235 (closed defect: fixed)

Opened 8 years ago

Last modified 7 years ago

Change VlanControl policy to better support LEARN/NLR

Reported by: ibaldin Owned by: yxin
Priority: major Milestone: Dungeness 4.0
Component: ORCA: Network embedding and stitching Version: baseline
Keywords: Cc:

Description

Currently we use VlanControl? for most of network provider and going forward this will be the control we will want to use. It needs to be altered (and a matching broker policy needs to be created) to allow for more flexible stitching, like e.g. with LEARN case, where currently we can only have one slice going out of LEARN. At issue is who has control of issuing specific VLAN tags - the AM or the broker. For stitching in some cases it appears that having the broker issues specific tags is advantageous.

This needs more notes and is pending a discussion (12/6/2011)

Change History

Changed 8 years ago by ibaldin

Label negotiation when translation is not available:

Need to have broker allocate labels (instead of quantities of labels).
Extract label ranges the broker policy can get from abstract NDL (no need for additional delegation properties).
Need to add group allocation of *compatible* resources, so if path requires label continuity between domains A and B, SM can say to the broker 'please give me 1 compatible resource from both A and B' meaning find an intersection of label ranges delegated by A and B and get 1 label out of it.

This requires request groups and atomic allocation within a group.

Jeff has certified this as 'architecturally consistent'.

Changed 7 years ago by ibaldin

in 3.1-extended have ExoSM remember enough state not to reuse labels given to other connections. Since only one ExoSM exists, this is sufficient.

Changed 7 years ago by ibaldin

  • status changed from new to closed
  • resolution set to fixed

Resolved as per recommendation above in 3.1-extended

Note: See TracTickets for help on using tickets.