1. 1 3/15/2016 Requirements on the O-UNI Olivier Duroyon, Alcatel Monica Lazer, AT&T Jen-Wei Kuo, Fujitsu Hirokazu Ishimatsu, Japan Telecom Zhi-Wei Lin, Lucent Mark Jones, Sprint Yang Cao, Sycamore Vijaya Poudyal, Telcordia Philip Walch, TyCom Yong Xue, UUNET/Worldcom Curtis Brownmiller, Worldcom

2. 2 3/15/2016 General Switched Network Architecture Control Plane Management Plane User Plane RA UNI CCI NMI-A -T AD1 AD2 E-NNI I- SNC OCC PI NE

3. 3 3/15/2016 Business Models Four business models to be supported –ISP owning all layer 1 infrastructure Complete trust – router & ONE all owned by one ISP –ISP owning partial or leasing layer 1 infrastructure May not have complete trust – router & ONE may be in separate admin domains –Retailer or wholesaler for multi-services Does not have trust – router & ONE in separate admin domain –Carrier’s carrier, or bandwidth broker Does not have trust – only ONE

4. 4 3/15/2016 ASON dial-up requirements Connection operations (create, modify, delete) –Various facets of modify – disruptive, non-disruptive –Need to define what constitutes non-disruptive, what disruptive Connection resilience –Specify availability of connection –Specify specific constraints SRLG, link disjoint, node disjoint, etc. –Should not specify service provider architectural solution, e.g., protection type used Protection type only a means to achieve resilience – e.g., availability

5. 5 3/15/2016 ASON dial-up requirements Control plane network resilience –Should not have dependencies of signaling network with transport network Allows for re-use of signaling network for control of other transport networks – GMPLS principle –Signaling network fail should not impact existing connections E.g., RSVP control plane failure would tear down existing connections? Scheduled connection services –Support for scheduled connection by different means Scheduling provided by user scheduler – no need for signaling Scheduling provided by service provider scheduler – signaling needed –Have we discussed and examined these different aspects E.g., if service provider  how to guarantee scheduled connection when network is composed of non-deterministic connection requests?

6. 6 3/15/2016 ASON dial-up requirements Naming & addressing requirements –Discussion still on-going among carriers requirements Support name (no semantics) or address (semantics) Use source/dest user names OR source/dest ONE names –OIF decided to use the latter Support multiple user name spaces (IP,ATM, NSAP) Who provides name/address translation/directory service (service provider will provide – current agreement) –Is there need for 2-phase address resolution What is need for user to query address and then use address to signal  redundant step? Is protocol limitations governing requirements  or should we extend protocol to support variable name types (up to 160 bits) –E.g., new C-type for a generic name?

7. 7 3/15/2016 Proposal IPO/CCAMP WG start first from requirements Requirements and framework work should be coordinated with other standards bodies (OIF carrier document, ITU G.astn) –Multiple Requirements and Framework I-Ds should be merged Signaling protocol specification need to meet the requirements –RSVP-TE for O-UNI (yu-mpls-rsvp-oif-uni-ext-00) –LDP for O-UNI (ietf-mpls-ldp-optical-uni-00)