1. Considerations on the Development of an Optical Control Plane draft-freeland-octrl-cons-00.txt Darren Freeland, Neil Harrison, Sergio Inglima, Keith James, Alan McGuire, Shehzad Mirza, Stewart Ritchie, Mel Robinson, Ali Salman, Peter Willis

2. Darren Freeland et al Considerations on the Development of an Optical Control Plane IETF49 San Diego - 15th December 2000  ID considers OTN control plane requirements  Protocol Independent approach  In response to exploder discussions  Current IETF approach  Extending IP control protocols to the OTN control plane.  May be the right answer, but has not been proven.  Based on assumption that “IP traffic volumes will dominate the OTN”  Is this argument valid though? …... Overview 1

3. Darren Freeland et al Considerations on the Development of an Optical Control Plane IETF49 San Diego - 15th December 2000  User Plane & Control Plane traffic need not be congruently routed in the OTN.  User Plane can accommodate large BW + new emerging client layers.  User Plane is agnostic regarding type of traffic it carries (ATM, IP, GbE, etc).  Is it valid to assume that control protocols developed for a CNLS environment are suitable for the CO OTN?  IP control plane should be analysed against OTN requirements. Nature of the OTN User-Plane OTN User Plane: - Connection Oriented (CO) - Circuit Switched - No buffering - Transparent to Clients - Control & User planes separable IP User Plane: - Connectionless (CNLS) - Packet Switched - Buffering - IP traffic only - Control & User planes congruent 2

4. Darren Freeland et al Considerations on the Development of an Optical Control Plane IETF49 San Diego - 15th December 2000 Some Carrier Issues  Large proportion of carriers require a multi-client OTN  Different types of client layer networks may have different control planes  Clients may use different naming/addressing schemes  De-coupling client & OTN layer control planes therefore...  ensures true multi-client OTN  ensures that support for future client layers is not hampered by legacy technology  Clients will generally not be given full visibility of the OTN  Topology/resource invisible to users at higher layers  Concern over type of info conveyed between carriers  Inter-working will generally be restricted to requests for service 3

5. Darren Freeland et al Considerations on the Development of an Optical Control Plane IETF49 San Diego - 15th December 2000 Control Plane facets  Naming & Addressing  Signalling Network  Interfaces  Signalling Protocol  Topology/Resource Discovery  Routing Process 4

6. Darren Freeland et al Considerations on the Development of an Optical Control Plane IETF49 San Diego - 15th December 2000  OTN control plane will receive set-up requests for 10’s of thousands of connections per day (per domain)  Addressing scheme must be scalable enough to cope with future demands  Control Plane network must be at least as reliable as User Plane network  Signalling failures should not affect existing user plane connections  Connection Admission Control (CAC) required at signalling interfaces  e.g. user authentication & permissibility, verification of service level parameters, billing  should provide a secure interface between the OTN and it’s various clients  OTN will consist of elements growing to the order of 1000+ ports  implies much larger # of links between neighbours (in contrast to higher layers)  routing processes must be able to scale in order to support them A few considerations 5

7. Darren Freeland et al Considerations on the Development of an Optical Control Plane IETF49 San Diego - 15th December 2000 Interfaces  Generally 2 types of control interface... O-UNI & O-NNI O-UNI other UNI IP/MPLS UNI FR/ATM UNI O-UNI i-ONNI e-ONNI OTN 2 OTN 1 FR/ATM client IP/MPLS client Other client Access D1  UNI may use in-band or out-band signalling  NNI should use out-band signalling 6

8. Darren Freeland et al Considerations on the Development of an Optical Control Plane IETF49 San Diego - 15th December 2000 Topology / Resource Discovery  OTN will consist of a number of administrative domains  owned by different carriers  requires distinction between NNI’s within and between domains  Topology/Resource discovery may be supported at i-ONNI  Topology/Resource discovery will not be supported at e-ONNI  Topology/Resource discovery will not be supported at OUNI O-UNI other UNI IP/MPLS UNI FR/ATM UNI O-UNI i-ONNI e-ONNI OTN 2 OTN 1 FR/ATM client IP/MPLS client Other client Access D1 7

9. Darren Freeland et al Considerations on the Development of an Optical Control Plane IETF49 San Diego - 15th December 2000  A number of carrier requirements are considered in draft-freeland-octrl-cons-00.txt  We propose that the list of conclusions from above draft be considered as a contribution towards the ‘IPO Framework’ ID.  Would also like to see an analysis of all control plane facets against carrier requirements for the OTN. Proposals 8