Overview

2. Overview • 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? …... 1

3. 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 • 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. 2

4. 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. Control Plane facets • Naming & Addressing • Signalling Network • Interfaces • Signalling Protocol • Topology/Resource Discovery • Routing Process 4

6. A few considerations • 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 5

7. IP/MPLS client FR/ATM client Other client IP/MPLS UNI other UNI FR/ATM UNI O-UNI O-UNI O-UNI i-ONNI O-UNI Access D1 e-ONNI OTN 2 OTN 1 Interfaces • Generally 2 types of control interface ... O-UNI & O-NNI • UNI may use in-band or out-band signalling • NNI should use out-band signalling 6

8. IP/MPLS client FR/ATM client Other client IP/MPLS UNI other UNI FR/ATM UNI O-UNI O-UNI O-UNI OTN 2 i-ONNI e-ONNI O-UNI OTN 1 Access D1 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 7

9. Proposals • 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. 8