IDC Notifications Andy Lake, Internet2 DICE, Ann Arbor, MI September 9, 2008

Overview Goals What information gets distributed? How does it get distributed? Use Case: IDC to IDC Notifications

Goals of IDC Notification Interface Publish information about IDC activity to interested consumers Network Monitoring Accounting Other IDCs End users Others... Each consumer has slightly different informational needs

Goals of IDC Notification Interface

Notification Information Types of events Resource scheduling results, was a path setup,did an error occur, etc Information about events Path, bandwidth, user, error code, error message, error source. etc

Distributing Notifications Follows WS-Notification by OASIS open.org/committees/tc_home.php?wg_abbrev=wsn open.org/committees/tc_home.php?wg_abbrev=wsn Consumers subscribe to notifications from producer Subcribe messages contain filters for types of notifications a consumer wishes to receive: Producer Topic (like log level)‏ Message Data (i.e. path, GRI, etc)‏ Authz info also determines the notifications a consumer receives

Design Questions Subscription filters can get fairly complicated so should an IDC have to worry about keeping track of which notifications to send where...in addition to tracking network resource availability and provisionings circuits? Are there other services (i.e. those in perfSONAR) that want to distribute notifications based on subscriptions filter and can the IDC solution be generalized?

NotificationBroker WSN defines a specification for brokered notification spec-os.pdf NotificationBroker is a service that distributes notifications on behalf of another service IDC only needs to send one message to NotificationBroker and the NotificationBroker will determine where it should be forwarded

NotificationBroker

NotificationBroker Implementation A brokered approach is not required OSCARS has separate NotificationBroker service included in 0.4 release (alpha released 9/8/08). Works with IDC but does not assume an IDC payload in notifications

Case: IDC-to-IDC Notifications Passing notifications between IDCs can be used to create more “asynchronous” protocol Asynchronous protocol desirable because: Circuit setup and other operations can take a long time Failures can happen at anytime IDC can wait for a “better” offer before reserving resources

Resource Scheduling Includes: createReservation, modifyReservation, cancelReservation Step 1: Accept request Step 2: Forward request toward destination domain Step 3: Send notification of CONFIRMED event back toward source domain Step 4:Send COMPLETED event back toward destination domain *FAILED event can happen between any of the above events

Resource Scheduling- Messaging

Resource Scheduling - IDC Internal State

Path Setup/Teardown Step 1: Accept request (user-xml) or start time reached (timer-automatic)‏ Step 1A: Forward request if signaling used Step 2:Each domain simultaneously performs setup/teardown Step 2A: Send CONFIRMED when local path setup finished Step 2B: Send DOWNSTREAM_CONFIRMED when receive same event from next domain and local domain finished. If last domain throw when local domain finished. Step 2B: Send UPSTREAM_CONFIRMED when receive same event from previous domain and local domain finished. If first domain throw when local domain finished. Step 3: When all 3 events received in step 2, mark circuit as ACTIVE and throw COMPLETED *FAILED event can happen between any of the above events

Path Setup/Teardown

Summary Many different types of consumers interested in IDC activity IDC event element defined in OSCARS.xsd Managing subscriptions can get complex so may be useful to have separate NotificationBroker Notifications can be used to create “asynchronous” IDC messaging