Hi Chin, all, Nice description. What I can add as ma extension here, is that user may request different "levels" of resiliency. We are in the research of various of those options at inter-domain level for AutoBAHN. We defined 3 attributes that are important from the user perspective for service resiliency (in the sense of circuit availability), which introduces various reactions to failures. The attributes are: - protection vs. restoration mode - intra-domain resiliency enabled / disabled - diversification of domains / domain re-use. The first attribute defines whether backup path is also scheduled/active (protection) or it will be searched at failure moment (restoration). Restoration is same as immediate reservation somehow, and can fail, while protection is rather assumed to be successful. This influence the design of protocol for reservation, as it must negotiate also this attribute. In consequence it states the probability of the resources on backup path will be available, and how fast can they be reachable (switching time). The second attribute defines whether domains has mechanisms to solve issues internally, without affecting global path (which was also included in your paper). If so, this kind of failures are transparent to NSI (NSI MAY be notified), as they can be solved by local network controllers. If at least one domain on a path does not support intra-domain resiliency, we consider whole path to not support it (yes, it's a simplification :) ) The last attribute defines, whether backup path should avoid domains/links from primary path. So in case whole domain is failed in a path, a backup path is not affected and can be used immediately (except circuit source and destination domain, which must be common). We made a matrix of those attributes (values 0/1 for any of three options in all reasonable combination) and received 5 levels of resiliency, that could be requested by users. Now is a matter on how dip are we wish to go with that for NSI. I personally think that resiliency can be weaker or stronger, and may be charged (even virtually) differently according to users credits/requirements. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania@man.poznan.pl Networking Center +48 61 858 20 28 http://www.man.poznan.pl ________________________________________________________________________
-----Original Message----- From: nsi-wg-bounces@ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf Of Chin Guok Sent: Wednesday, April 21, 2010 7:49 AM To: nsi-wg@ogf.org Subject: [Nsi-wg] NSI error handling draft
Hi all,
I've attached a draft of the error handling section that Inder and I came up with for the NSI Architecture document.
This is a rough first draft, and there are some obvious portions missing, but it gives an idea of where we heading.
Comments are most welcomed.
Thanks.
- Chin