Optical Transport Use Cases. Optical Transport Working Group

Transcription

1 Optical Transprt Wrking Grup

2 Optical Transprt Wrking Grup ONF Dcument Type: Technical Paper ONF Dcument Name: ptical-transprt-use-cases Disclaimer THIS SPECIFICATION IS PROVIDED AS IS WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Any marks and brands cntained herein are the prperty f their respective wners. Open Netwrking Fundatin 2275 E. Bayshre Rad, Suite 103, Pal Alt, CA Open Netwrking Fundatin. All rights reserved. Open Netwrking Fundatin, the ONF symbl, and OpenFlw are registered trademarks f the Open Netwrking Fundatin, in the United States and/r in ther cuntries. All ther brands, prducts, r service names are r may be trademarks r service marks f, and are used t identify, prducts r services f their respective wners. Open Netwrking Fundatin

3 Table f Cntents 1 Intrductin Use Case 1: Phtnic Enterprise Netwrk Envirnment Operatin Prvisining Recvery Mnitring Netwrk Inventry Benefits Use Case 2: Carrier Ethernet Netwrk Virtualizatin Envirnment Preliminaries Operatin Future Wrk Benefits Use Case 3: Optical Netwrk Service Prvider Data Center Intercnnectin (DCI) Envirnment Operatin Virtual Netwrk Service Establishment Virtual Netwrk Cnnectin Fault Mnitring, Detectin, and Recvery Benefits Use Case 4: Packet-Optical Integratin Envirnment Operatin Cntrller Relatinships CDPI Operatin fr Multi-Layer Cntrl Hierarchical Cntrller Operatin Benefits Appendix A: Virtual Netwrks Appendix B: Appendix C: Acrnyms Glssary

4 1 Intrductin A use case describes the actins taken by a hypthetical set f actrs as they wrk t achieve a gal. The actrs may be human, but they are ften sftware entities r rganizatinal entities. The purpse f the use case is t present a believable scenari that assists in identifying architectural cmpnents, relatinships and requirements. This dcument applies thse principles t the sftware-defined netwrking (SDN) cntrl f transprt netwrks. It describes fur use cases related t transprt netwrks. Its intentin is t guide the develpment f high-level requirements, architecture, and prtcl definitin fr Transprt SDN. Briefly, the use cases are: Direct cntrl f ptical cmpnents in enterprise netwrks Carrier Ethernet netwrk virtualizatin Service prvider data center intercnnectin Packet-ptical integratin The use cases in this dcument are designed t illustrate nly sme f the pssible applicatins f SDN in the transprt netwrk envirnment. The list is nt exhaustive r final; there are many ther pssible applicatins and mre may be investigated in the future. The intent is t present and analyze the use cases in a way such that high-level requirements can be derived frm them. The use cases are nt intended as detailed specificatins fr realizatin. In the interest f brevity, the use cases aim t describe realistic netwrk and peratinal scenaris withut supplying extraneus details; further, the reader shuld be aware that any details that are presented may nt apply t all scenaris. The dcument prvides sufficient detail t identify differences between existing methds f peratin and the use f SDN/OpenFlw, and identify functinal requirements n SDN/OpenFlw t supprt these use cases. 2 Use Case 1: Phtnic Enterprise Netwrk This use case addresses enterprise data center intercnnectin by a private all-ptical netwrk, where the netwrk is wned and perated by the same enterprise that wns and perates the data centers. It is assumed that the purely phtnic part f the netwrk is bunded and supprts a limited number f large flws n a wavelength basis. Such phtnic islands may be intercnnected via OEO equipment fr scaling reasns, but the OEO aspect is beynd the scpe f this use case. As a result, it is suitable t rute n a wavelength basis, assuming that nly a WDM netwrk is intercnnecting the ndes. 2.1 ENVIRONMENT Data center services that may be ffered by the enterprise t third parties are nt included in the scpe f this use case, and the netwrk tplgy is assumed t be knwn t the SDN cntrller. As such, n cntrl-virtual netwrk interface (CVNI) is shwn in the envirnment diagram f Figure 1. While nly tw data centers are shwn, the use case allws fr any number. 4

5 SDN cntrller CDPI Multi-wavelength clred interfaces CWDM/DWDM netwrk Multi-wavelength clred interfaces Transpnder/ Muxpnder Gray interfaces, e.g., 10GE, 40GE, 100GE Packet switch/ Ruter Gray interfaces, e.g., GbE, 10GE Gray interfaces, e.g., GbE, 10GE Packet switch/ Ruter Server... Server Server... Server Data center 1 Data center 2 Figure 1 Data center intercnnect, all-ptical netwrk As illustrated in Figure 1, a data center cntains a number f servers, where the applicatins are hsted, and the data center fabrics may cnsist f ruters and packet switches. Tw cases are shwn. In Data Center 1, the packet switch may have gray interfaces t a transpnder r muxpnder, which is respnsible fr prviding WDM wavelength signals. In Data Center 2, the WDM wavelengths are prvided directly by the packet switch. In bth cases, the fibers enter a CWDM/DWDM netwrk, which cmprises an arbitrary arrangement f passive ptical devices, active ptical devices, and ptelectrnic devices that perfrm the transprt functin, but d nt demultiplex signals beynd the wavelength level. The netwrk may cntain wavelength-selective switches, ROADMs, ptical mux/demux equipment, ptical amplifiers, and/r recnfigurable ptical crss-cnnect devices. It is assumed that the netwrk is designed t prevent a path cmputatin functin frm cnfiguring nnperable cmbinatins f ptical cmpnents, and t assure that the additin r remval f an ptical signal n a path will nt render any f the existing signals in the netwrk nn-viable. This may be achieved by engineering individual cmpnents fr wrst-case applicatins, by impsing cnstraints n the recgnized and allwed tplgy available fr path cmputatin, r by ther means. The path selectin functins are assumed t reside in the cntrller and are nt in the scpe f this dcument. 5

6 All active devices are assumed t implement the cntrl-data plane interface (CDPI), and all are cntrlled by a cmmn SDN cntrller. (Fr simplicity, server cntrl channels are nt shwn in the drawing.) Discussin f allwed verhead, supervisry, r auxiliary channels thrugh the ptical netwrk is nt included in this use case. 2.2 OPERATION This sectin describes the peratin f the SDN cntrller and netwrk elements fr different actins within the use case Prvisining When cnnectivity r capacity demands frm the data centers change, the SDN cntrller is instructed t add r reduce capacity between data centers. The cntrller may d this in several ways: Redirecting a wavelength frm a given surce t a different destinatin. Re-tuning a transmitter t a new wavelength (while aviding disruptin t ther circuits*) in rder t establish a new cnnectin t a different destinatin. Activating a new cnnectin by turning up a previusly dark transmitter t add capacity. De-activating a cnnectin by turning dwn a currently active transmitter t reduce capacity. Implementing this actin may require the SDN cntrller t make cnnectivity r parameter changes in a number f netwrk elements. Because the netwrk engineering rules ensure that nly ptically viable paths are selected, the issue f excessive impairment des nt arise. Hwever, minr adjustments such as pwer balancing are still carried ut as apprpriate. Any such adjustments must ensure that the parameters remain within specified ranges that enable viability. These adjustments may be calculated either in the equipment itself r thrugh the SDN cntrller Recvery When a cnnectin fails, the SDN cntrller must perfrm the actins required t maintain the desired service level. The transprt ndes must ntify the SDN cntrller f the failure f a cnnectin within the time required s that the SDN cntrller can take the apprpriate actin. These actins may include ntificatin t the client r establishment f a new cnnectin. The allcatin f respnsibility and actins taken depends n the maximum time that a service may be disrupted befre recvery and verall availability. Within the use case there are three pssibilities, depending n the type f failure and the service being supprted: The desired service level is such that it is acceptable fr the cnnectin t be recvered by nrmal maintenance/repair actins. Depending n the lcatin and type f failure, recvery may take hurs t days. The desired service level is such that it is acceptable fr the cnnectin t be recvered by the SDN cntrller establishing a new cnnectin t replace the failed cnnectin. The desired service level is such that it is desirable fr the recvery actin t be delegated t autnmus prtectin/restratin mechanisms within the transprt netwrk. In this case, when the riginal cnnectin is set up, it must include the cnfiguratin f the required prtectin/restratin * Tuning while active may disrupt ther active cnnectins. Re-tuning must be a multi-step prcess: 1) turn dwn; 2) re-tune; and 3) turn up. 6

7 resurces. If recvery actin is enabled in bth server and client layers, the initial cnnectin setup must include the infrmatin required t avid a single failure in the server layer causing transient switching in the client layer. When the wrking r prtectin entity fails, the SDN cntrller must be ntified. Depending n the desired service level and the expected repair time, the SDN cntrller may set up a new prtectin/recvery path. If bth the wrking and prtectin entities fail, the SDN cntrller may establish a new cnnectin t recver the service Mnitring Mnitring f the ptical layer may be perfrmed t supprt practive maintenance, t supprt fault lcalizatin, r as input t SLA assurance. The degradatin f an ptical path may at sme pint cause a failure in the cnnectin that is using that path. The SDN cntrller may have the capability t cmpensate fr the degradatin and must have the capability t issue ntificatins f any degradatin and prvide a reprt n request. This may invlve the analysis f parameters retrieved frm (r reprted by) ne r mre netwrk elements. If a netwrk element is capable f detecting the degradatin f an ptical path, it must ntify the SDN cntrller when the degradatin exceeds a preset threshld. This threshld may be preset within the equipment r it may be cnfigured during installatin r peratin. If a netwrk element supprts mnitring f individual ptical parameters, r sets f parameters, the netwrk element must ntify the SDN cntrller when any f the parameters exceeds a predefined range. The range may be preset within the equipment r it may be cnfigured during installatin r peratin. Parameters that may be mnitred include transmitted ptical pwer level, received ptical pwer level Netwrk Inventry The SDN cntrller must be able t retrieve r be prvided with infrmatin abut the netwrk that it is cntrlling. Equipment inventry: A netwrk element must be able t prvide infrmatin related t the hardware that has been deplyed and is under the authrity f the SDN cntrller. This may include, but is nt limited t: Sub-elements that may be present within the netwrk element (e.g. shelves and plug-in units). Capabilities that are supprted (e.g. client/server adaptatins, applicatin cdes, wavelength range, transmitted and received min/max pwer levels, mdulatin frmats, FEC type, service supprted, etc.). Cmpnent usage state (e.g. active, idle, busy). Cnnectivity inventry: A netwrk element must be able t prvide a list f the cnnectins that it is currently supprting, if it supprts lcal state infrmatin f cnnectins, Link characteristics: These include, but are nt limited t, link lss, distance, and latency. These may be prvided either by the netwrk element r specialized test equipment, r cnfigured directly in the SDN cntrller. Netwrk tplgy: The SDN cntrller must have full knwledge f the netwrk tplgy, including hardware cnnectivity. This knwledge may be prvided directly t the cntrller, r by retrieving the results f any discvery prtcls that are supprted by the netwrk elements. 2.3 BENEFITS In the absence f dynamic ptical services being available frm lcal prviders, Transprt SDN wuld enable enterprise IT departments t functin as their wn service prviders, managing their cnnectivity 7

8 and allcating bandwidth between sites in minutes rather than waiting fr the lcal prvider t fulfill a fixed-line change rder. With Transprt SDN, enterprises can switch wavelengths between lcatins t allcate bandwidth amng sites as needed by their applicatins. 3 Use Case 2: Carrier Ethernet Netwrk Virtualizatin This use case illustrates sme fundamental aspects f netwrk virtualizatin in a Carrier Ethernet applicatin a MEF E-line service 1. Crucial aspects f this use case include the recgnitin f business r rganizatinal bundaries, alng with infrmatin hiding and namespace translatin. As well as static establishment, the use case includes a few illustrative examples (nt a cmplete list) f the kinds f activities that a virtual netwrk client can expect t be able t perfrm. 3.1 ENVIRONMENT Figure 2 illustrates a simple physical netwrk, cmprising fur netwrk elements designated NEs 1 4. In this use case, NE1 is represented as having m physical prts n its east side, while NE 4 has n physical prts n its west side, identified by <NE>.<rdinal><E/W>. Prt 1.1E is assumed t be an unclred GbE r 10GE ptical prt; the nature f ther physical prts is shwn in Figure 2, als nly as examples. Dmain f Client C2 Client C2 cntrller Client C1 cntrller Dmain f Client C1 CVNI Dmain f Netwrk Prvider NP1 Prvider interface CDPI VC Virtualizer Other functinal blcks in cntrller Netwrk Prvider Cntrller NPC NE 2... IP Phy (gray ptics) 4.1W NE 4 NE 1 1.1E 4.nW NE 3 1.mE UNI Client C1 hst A... IP LO ODU HO ODU OCh Clred ptics... IP LO ODU HO ODU Gray ptics Figure 2 Physical netwrk, single prvider dmain As indicated by the heavy dashed line, the NEs and the netwrk prvider s cntrller (NPC) are wned and perated by a single business entity, Netwrk Prvider 1. NP1 manages the netwrk by way f a prvider interface, which includes bth management f the netwrk itself and an interface VC fr 8

9 cnfiguratin and management f the virtualizer functin. Cnventinal r evlved EMS/NMS systems may use the prvider interface, and the NPC may be transparent r semi-transparent t EMS/NMS flws. Fr purpses f this descriptin, all cntrl and management entities that may appear at the prvider interface are understd t be crdinated in their views f netwrk infrmatin and state. The prvider interface is nt expected t be standardized. Cntrller NPC has full visibility f and unrestricted access t all NEs. This use case des nt distinguish between OF-switch and OF-cnfig. The nrth and suth interfaces frm the NPC are called CVNI and CDPI, as shwn. Thrugh a virtualizer functin, NP1 ffers virtual netwrk services t clients, fr example C1 and C2. NP1, C1, and C2 represent separate business entities. NPC therefre represents and enfrces a business bundary, which includes functins such as security (AAA), independence between client VNs, infrmatin hiding, namespace translatin, and address space islatin via encapsulatin. The virtualizer ensures that C1 and C2 can neither see nr affect each ther. The virtualizer cntrl interface VC is a trusted interface wned by NP1. There is n business bundary, and infrmatin and cntrl are fully transparent acrss this interface. VC is the means by which the business entity NP1 cntrls the virtualizatin functins f NPC. Figure 2 als illustrates greatly simplified prtcl stacks that may be visible at varius interfaces. The UNI at prt 1.1E, fr example, is assumed t be a GbE r 10GE Ethernet private line service that matches the service request frm Client 1 fr hst A's cnnectin. Ethernet services may be transprted in the netwrk using a variety f technlgies; the prtcl stacks shwn at the NE 1/3 and NE 3/4 NNIs are ne pssible example. Other pssibilities such as MPLS, PW encapsulatin, r additinal TDM encapsulatins are mitted. NE 1 is an edge nde that adapts custmer traffic nt a single-wavelength OTN. At NE 3, the signal may be further multiplexed int an OTN wavelength (ptical channel OCh), which ultimately hands ff the traffic at NE 4, where there may be anther UNI r an NNI int the dmain f anther netwrk prvider NP Preliminaries This descriptin is written arund activities taken by Client 1 by way f its SDN cntrller. C2 culd d the same r different things; tw clients are shwn t illustrate generality. Befre anything can transpire acrss the CVNI bundary between the C1 cntrller and the NPC, each party must establish whatever security is cntractually deemed apprpriate with regard t the ther. Security cnsideratins are imprtant, but are beynd the scpe f this use case. Client 1 s hst cmputers attach t NP1 s netwrk thrugh physical media. Either party may r may nt deem the physical plant t be tamper-prf. This pint is pursued further in the Operatins sectin. In general, Client 1 s SDN cntrller will cmmunicate with the NPC ver arbitrary physical channels, s physical security can rarely be assured. At a minimum, the NPC must be prvisined with C1 s credentials. A prudent client cntrller will als insist n having the NPC s credentials. Bth sides must als be prvisined with security plicies; fr example, the encryptin t be used acrss the CVNI, the number f parallel pen sessins allwed, and idle sessin timeut. Befre netwrk peratins can begin acrss the CVNI bundary between the C1 SDN cntrller and the NPC, they must share a cmmn view f the virtual netwrk. Establishing interface pints f presence (POPs) is at best a cntractual negtiatin, and at wrst may als require the installatin f fiber and equipment. Once the POPs are agreed n, NP1 uses interface VC t cnfigure the virtual netwrk int the NPC, which is respnsible fr expsing the cntracted virtual netwrk t the client. Figure 3 shws the simplest pssible virtual netwrk, a set f distributed prts surrunding a single virtual netwrk element. 9

10 C1 hst Z Z C1's virtual netwrk (element) (4.nW) (1.1E) A C1 hst A Figure 3 C1 s virtual netwrk The view exprted t C1 must be in terms f identifiers (names) knwn t C1, in this case, prts A and Z. Assciating these identifiers with prts in NP1 s netwrk is the respnsibility f the virtualizer as cnfigured via VC. In this use case, C1 prt A is assciated with NP1 s prt 1.1E; C1 prt Z is assciated with NP1 s prt 4.nW. It is pssible that NP1 prpses identifiers (pssibly aut-generated) and the client simply accepts them. An example f such names fr Client 1 might be C1:A, C1:B, etc. It is als pssible fr the client t specify the names (fr example A, B, etc.), which wuld then be accepted by NP1. In either case, the NPC must maintain mapping between the client s names and its wn resurces. In this use case, fr example, the client name C1:A (r just A, in the knwn cntext f Client 1) maps t prt NP1:1.1E. Transactins between C1 and NP1 acrss the CVNI n C1 s virtual netwrk ccur nly in C1 s namespace. This simplest pssible use case expses nly POPs t the client, with n details f their intercnnectin tplgy. Cnnectivity, bandwidth, and SLA cmmitments have been negtiated statically. As seen in the fllwing sectin, there are several aspects t the cnfiguratin f a virtual netwrk beynd a simple view f tplgy and cnnectivity: Agreement n a client namespace, alluded t abve. Because VN client address spaces may verlap with each ther, and may als verlap with the prvider address space, encapsulatin (address mapping) may be required fr address space islatin. Cnfiguratin f plicy; i.e., what the client is and is nt allwed t d. If Client 1 were t subcntract netwrk services t Client 11, it wuld have its wn equivalent f VC and NPC, but remain entirely within the cnstraints f the virtual netwrk subcntracted frm NP OPERATION In this use case, Client 1 purchases a MEF-6.1 E-line service, chsen as a real-wrld example f Carrier Ethernet service. Figure 4 shws NP1 s view f the resulting service as a heavy dtted line. 10

11 C1 hst Z end Client C1 dmain Client C1 cntrller C1 hst A end Netwrk prvider NP1 dmain CVNI Prvider interface VC Virtualizer Other functinal blcks in cntrller Netwrk prvider cntrller NPC NE 2 CDPI... IP Phy (gray ptics) Z 4.nW NE 4 NE 3 NE 1 1.1E A... IP LO ODU HO ODU OCh Clred ptics... IP LO ODU HO ODU Gray ptics Figure 4 NP1 s view f C1 s service Via VC, NP1 establishes the plicies that allw C1 t view and cntrl functins within its virtual netwrk, several examples f which are illustrated belw. The examples are intended t illustrate the scpe f the necessary functinality, but are neither all-encmpassing nr mandatry. E-line service t be created between prts C1:A == NP1:1.1E and C1:Z == NP1:4.nW, with given bandwidth, delay, jitter, and availability characteristics. (See MEF 10.2 fr the list f service attributes 2.) Namespace agreement is described abve. On request frm C1, the NPC cmputes and sets up the path between prts 1.1E and 4.nW, satisfying the cntractually negtiated SLA criteria. The NPC may invke the services f a PCE. Figure 4 shws the physical netwrk as an OTN with clred and gray ptics as an example, but multiple layers may be used t transprt the service cnnectin (at the discretin f NP1) frm wavelengths, t TDM, t L2 and L2.5 frwarding. The NPC cnfigures the NEs t plice and/r shape traffic frm C1's hsts A and Z, as and if required fr SLA enfrcement. NP1 is respnsible fr prviding the apprpriate mapping/translatin between the client, NP, and physical netwrk resurce names. The mapping/translatin functin allws the supprt f independent and pssibly verlapping namespaces. Traffic frm different clients must be islated in the transprt netwrk. The NPC cnfigures the NEs t prvide this islatin using mechanisms apprpriate t the cre netwrk technlgy (e.g. wavelength, timeslt r packet assignment, r encapsulatin). The methd f islatin and its attributes are invisible t the client. Operatinal security: this use case is an Ethernet service; C1 may request that NPC instantiate an 802.1X client 3 n Prts A and Z t cntrl access frm its Hsts A and Z. This is nt t be cnfused with security between the NPC and the client cntrller C1 itself. If NPC ffers this service, there may als be a need t direct the resulting radius messages t an AAA server smewhere else in C1 s virtual netwrk, r NPC may hst the AAA functin itself as an added-value service. 11

12 C1 hst Z Z C1's virtual netwrk (element) (4.nW) (1.1E) A C1 hst A MEP MIP Figure ag CFM, C1 s view Figure 5 shws that C1 may chse t instantiate an IEEE 802.1ag MEP 4 frm Prts A and Z t its lcally cnnected hst equipment. C1 als instantiates a MEP n its hst equipment at either end t cnfirm end-t-end cnnectivity. While the hst MEPs are beynd the scpe f NPC, MIP behavir is required at prts 1.1E and 4.nW. Bth MEPs and MIPs are prvisined by Client 1 via NPC, using C1 s names A and Z. C1 cnfigures its lcal MEPs, thse between C1 s VN and its hsts, t generate CCMs at 10ms intervals. Fr this use case, suppse that, if C1 tried t specify 3.3ms intervals, NPC wuld deny the request, because NP1 has installed a plicy t prtect its resurces frm verlad. On the ther hand, the cnfiguratin f C1 s end-end (hst-based) MEPs t generate CCMs at 3.3ms (r in any ther way) is f n cncern t NP1. Suppse there is a failure r pwer lss between NP1 s prt 1.1E and the client. Incming lss f signal frm C1 hst A is flagged by NE 1 as an LOS ntificatin against prt 1.1E, and reprted by NPC t C1 as a ntificatin against prt A. As t alarm treatment, there are tw extremes f cntractual agreement. At ne extreme, the NPC may prvisin NE 1 t reprt a critical alarm, which will cause NP1 persnnel t respnd immediately. The NPC wuld prbably als frward a critical alarm t C1. At the ther extreme, C1 may have cmmitted cntractually t the intentinal pwer-dwn f its netwrk frm time t time, in which case NE 1 may nly reprt a nn-alarmed LOS event, and the NPC may nly frward a nn-alarmed event. If C1 intentinally shuts dwn a critically mnitred interface, it can suppress spurius alarms by administratively lcking prt A. This als blcks service n prt A. It is a matter f prvider plicy whether this actin als suppresses prt 1.1E ntificatins t the NPC. Client 1 can als suppress prt A alarms withut affecting service thrugh alarm severity settings (change t nt-reprted). It is a matter f prvider plicy whether NE 1 cntinues t ntify the NPC abut events n prt 1.1E. C1 requests PM cllectin via its interface int the NPC. Request and results are expressed in terms f C1 s names, A and Z. C1 cnfigures threshlds n the PM and expects t receive ntificatins when the threshlds are crssed, als in terms f the names A and Z. T mnitr SLA cmpliance, NP1 may establish internal PM cllectin, the same data and threshlds as cllected by C1, r different nes. If data r threshlds are different, the NPC is respnsible fr cnverting the underlying data t C1 s view. C1 expects ntificatins f events that affect its service (fr example, unrecverable failures inside NP1 s netwrk) t be presented in terms f its prt identifiers (names) and SLA. C1 chses which ntificatins t subscribe t, within the set allwed by NP1 s plicy as prvisined via interface VC. T reslve truble calls, NP1 will als wish t see PM and ntificatins in the frm reprted t C1. Prt 1.1E is dedicated t C1. In additin t being able t administratively lck the prt, C1 is allwed t set and retrieve parameters specific t the physical prt, such as FEC chices r received ptical pwer level. 12

13 Given that, by hypthesis, C1 nly subscribed t an availability figure, and des nt have visibility f prtectin, NP1 is respnsible fr failure recvery thrugh prtectin switching r re-ruting. C1 cannt take steps t recver frm netwrk failures because C1 has nn-redundant POPs at A and Z, and n tplgy view. NP1 ntifies C1 nly if the SLA cannt be satisfied after a failure. It wuld als be pssible fr C1 t have sme visibility and cntrl f prtectin (fr example, at L2 via LAGged POPs) with physical prtectin that remains in NP1 s dmain. Physical prtectin visibility and cntrl may be ffered t C1 if C1 cntracts fr full wnership f physical links. (Shared resurces cannt be cntrlled by mre than ne client.) Intermediate levels may be apprpriate when mre virtual netwrk tplgy is expsed. The NPC has a set f respnsibilities: NP1 cnfigures internal functins such as OTN trail trace r 802.1ag/BFD CFM. NP1 mnitrs receive ptical pwer r ther measures f SNR, such as uncrrectable FEC blcks. The NPC interprets cmmands, respnses, and ntificatins between C1 s names and NP1 s resurce designatins. The NPC maps cmmands, respnses, and ntificatins between C1 s virtual netwrk view and the underlying netwrk resurces. A cmmand at CVNI may expand int a number f cmmands at the server layer, directed t a number f different physical equipment units and links, while nrthbund infrmatin may need t be cnslidated befre being presented t the client. The NPC ensures that traffic is islated between clients, even if they use the same addresses internally e.g., VLAN IDs r IP addresses. If the handff pints frm C1 t NP1 were TDM r wavelengths, with n internal packet visibility thrughut NP1 s netwrk, islatin culd be perfrmed at the level f TDM r wavelength switching. In packet space, this is achieved with encapsulatin. If C1 s cntrller is an OpenFlw cntrller, it functins in C1 s address space, and des nt knw abut encapsulatin. The NPC s encapsulatin/decapsulatin respnsibility therefre includes adding/stripping uter addresses that are passed between the physical netwrk and C1 (OpenFlw cmmands, respnses, and packet-in, packet-ut messages). That is, classificatin rules in the physical switch may cntain match fields unknwn t C1, but supplied by NPC; likewise with actins fr encapsulating utging packets. Cnversely, packets frwarded frm the switch t C1 will have their utermst encapsulatin remved by NPC Future Wrk Althugh it des push sme bundaries f what is reasnable, this use case is intended t intrduce virtualizatin in the simplest pssible terms. Further use cases culd be written arund scpe extensins in several dimensins. Examples include: Mre cmplex services e.g., multipint, L2.5, L3. Ability fr C1 t set up cnnectins r define SLAs dynamically n particular cnnectins, still wrking in its wn namespace, either using circuit cnnectins r by way f packet frwarding. Learning in the packet wrld, L2 and L3. Shared resurces at the POPs, with the need t specify sme r all f wavelength, high- and lwrder TDM, PW encapsulatin, VLAN tagging, etc., as selectrs f lgical prts rather than physical prts. C1 subcntracts its view f the netwrk t Client 11, Client 12, etc. In such a case, C1 then enfrces a business bundary with its wn clients, and has its wn virtualizer cntrller and netwrk prvider cntrller, all bunded by the scpe f the virtual netwrk it has cntracted with Netwrk Prvider 1. Netwrk Prvider 2 interfaces with NP1 at sme set f NNI prts, and a client cntracts fr a service that crsses the bundary. In sme cases, handff between prviders wuld be negtiated between prviders in a subcntractr relatinship, and the client wuld see a single service and billing interface. 13

14 3.3 BENEFITS This use case highlights the highly flexible netwrk virtualizatin achieved thrugh the use f SDN in cntrl f transprt netwrk elements and services, in this case Carrier Ethernet services as represented by a MEF E-Line service. Netwrk resurces can be allcated t multiple clients and cntrlled by each client cntrller as if it was cmmunicating directly t netwrk elements in a dedicated dmain. A virtual netwrk must be predefined befre a client and a server can request r prvide service. This is prbably a manual prcess that invlves technical and gegraphic factrs and business agreements. In such a case, (virtual) netwrk discvery is a prcess f cnfirming interface and tplgy structures that have been agreed cntractually and prvisined (semi-)manually. Hwever, annymus and interchangeable resurces internal t a virtual netwrk, such as servers in a data center, have n static external interface definitins and may be created, deleted, and discvered. It is fr further study hw a client with an existing business relatinship culd attach t a netwrk, pssibly dynamically. Wireless raming use cases and technlgy wuld be at least the starting pint fr this wrk. A physical switch may need t supprt at least ne frm f encapsulatin t cater fr arbitrary client address spaces. A physical switch may need t terminate a virtual flw (classificatin n uter address) and then frward the cntents f that flw based n inner addresses. Physical switches supprting such virtual switch r ruter functinality may need the ability t lgically pass traffic thrugh a classifierfrwarder multiple times. 4 Use Case 3: Optical Netwrk Service Prvider Data Center Intercnnectin (DCI) This use case addresses data center intercnnectin (DCI), serving traffic flws between separate data centers (DCs) ver an ptical transprt netwrk. One f the main characteristics f this use case is that the prvider netwrk is shared with ther client traffic. Anther characteristic f this use case is the cntrl separatin f the DC and prvider netwrk. DCI cntrl refers t cntrl f netwrking beynd a DC that is, an rchestratin abve DCs. It crdinates with the transprt netwrk, allwing crdinatin f cnnectins between different DCs and acrss multiple applicatins. This use case recgnizes differentiatin between wnership f DC and netwrk resurces t allw different ptimizatins. Fr example, the DC and the netwrk culd be wned by the same prvider, giving the ability t cntrl bth DC applicatins and netwrk resurces, e.g., scheduling t maximize utilizatin. In anther example, the DC and the netwrk culd be wned by different rganizatins (e.g., private and public) r a mix (e.g., clud bursting, the dynamic deplyment f a sftware applicatin that runs n internal rganizatinal cmpute resurces t a public clud t address a spike in demand). Optimizatin pprtunities in this case wuld be mre limited. There are tw sub-use cases: Case 1: The netwrk prvider s data centers are intercnnected via its wn transprt netwrk. The separatin f DC and netwrk cntrl is a cnsequence f crprate rganizatin r skill sets, but the netwrk cntrller trusts the DC cntrller. Case 2: Third-party data centers are intercnnected via the netwrk prvider s transprt netwrk. Fr case 1, the DC cntrller is an internal client t the netwrk prvider cntrller (NPC); fr case 2, the DC cntrller is an external client t the NPC. Because case 2 requires tighter cntrl in terms f plicy, security, and the degree f infrmatin sharing between the DCs and the netwrk, discussins are based n case 2 unless stated therwise. This use case cmplements Use Case 2 (UC2). While UC2 describes the cncept f netwrk virtualizatin and its cmpnents in general settings, the fcus f this use case is t cntextualize the 14

15 cncept described in UC2 int a data center intercnnectin setting, and t prvide cncrete wrkflws needed between the NPC and DC cntrller fr virtual netwrk service establishment, virtual netwrk cnnectin, and fault mnitring, detectin, and recvery. Specifically, this use case prvides an autmated prcess f verifying interface and tplgy structures that have been agreed cntractually between the NPC and the DC cntrller. This use case als demnstrates the use f dynamic/autmated recnfiguratin f a virtual netwrk service, which may, fr example, be required fllwing cntractual changes t the service. 4.1 ENVIRONMENT Current DCI is based n pre-allcated static WAN ptical pipes between DC sites. This pre-allcated capacity may be engineered fr peak rates and thus underutilized much f the time due t fluctuating traffic demands. This mde f peratin is nt suited t dynamically allcating new applicatins t ne ut f a number f candidate DC sites while adjusting the WAN bandwidth accrdingly. Fr example, sme wrklads r data may need t be migrated n the fly frm ne data center t anther. Disaster recvery is anther example in which a large amunt f data may need t find alternative data centers when the currently serving data center experiences an utage affecting applicatin perfrmance. Figure 6 Data center intercnnectin architecture Figure 6 depicts a high-level netwrk architectural cntext fr this use case. The service prvider s transprt netwrk may supprt a number f different client applicatins, including DC intercnnectin. There are a few assumptins: The DC cntrller knws all its DC endpint interfaces that are cnnected t the prvider netwrk. A data plane cnnectin between each DC endpint interface and a crrespnding netwrk prvider endpint interface (i.e., UNI) is assumed t have been established prir t cntrller cmmunicatins between the DC cntrller and the NPC. (This assumptin may be replaced by dynamic establishment f a data plane cnnectin in a use case that supprts dynamic attachment t the prvider netwrk, e.g., via wireless access technlgies.) 15

16 A service cntract is in place between the DC peratr and the service prvider that sets the relevant plicies regarding the peratin f the service(s) available t the DC peratr (and by extensin t the DC cntrller). The NPC knws the prvider netwrk endpint interfaces that are cnnected t DCs perated by the DC peratr and cvered by the service cntract. (This assumptin may be replaced by an authenticatin mechanism in a use case that supprts dynamic attachment t the prvider netwrk, e.g., via wireless access technlgies.) The DC cntrller has full visibility f each data center under its cntrl. This visibility includes DC resurce, DC lcatin infrmatin, interfaces t prvider netwrks, and ther user/applicatin-related infrmatin. Multi-layer r packet ptical integratin (POI) aspects f transprt netwrks are cvered in Use Case 4 f this dcument. Fr the DC intercnnectin applicatin, the client cntrller is the DC cntrller, which can be an internal entity r an external entity with respect t the relatinship with the service prvider. Each data center may have a lcal DC cntrller, and these DC cntrllers may frm a cnfederacy r hierarchy t interface the NPC. Hw these DC cntrllers are rganized t present a unified interface t the NPC is beynd the scpe f this dcument. Fr purpses f this use case, a single lgical DC cntrller is assumed t cnnect t a single lgical NPC. 4.2 OPERATION Three use case scenaris and wrkflws are described in this sectin. Virtual netwrk service establishment Virtual netwrk cnnectin and virtual netwrk element cnnectin Fault mnitring, detectin, and recvery Virtual Netwrk Service Establishment This use case scenari is cncerned abut pre-virtual netwrk cnnectin infrmatin exchange and its wrkflw. This prcess invlves negtiatin f virtual netwrk service (VNS) between the DC cntrller and the NPC within the cnfines f the established business agreement. This prcess meets tw bjectives: t verify the established business agreement between the DC peratr and the service prvider, and t autmate business negtiatin/re-negtiatin and the virtual netwrk service (VNS) creatin prcesses. A custmer defines the need fr a virtual netwrk within the prvider s transprt netwrk, then cntacts the service prvider t negtiate a cntract fr VNS. The custmer prvides a traffic demand matrix as part its VNS request, and the service prvider cmputes and presents t its custmer ne r mre virtual netwrks (VNs) that wuld supprt the requested bjective, including bandwidth. Each VN cnsists f ne r mre virtual netwrk elements (VNEs), which are intercnnected by virtual links. These links can be characterized by a number f attributes, including cmmitted bandwidth, excess bandwidth, latency, maximum number f supprted cnnectins, etc. (See Appendix A fr VN examples.) The negtiatin f VNS is per VNS instance. The VNS must be instantiated befre the first virtual netwrk cnnectin is t be set up. The instantiatin f the VNS will result in the allcatin f the cmmitted resurces f the VN. The resurces in the netwrk path in the subnetwrk (e.g., crss cnnect resurces) are nly allcated when the VNE cnnectin setup is perfrmed Negtiatin initiatin This descriptin is written arund negtiatin between the DC cntrller and the NPC. The actr that initiates negtiatin is the DC cntrller. As a client t the transprt netwrk, the DC cntrller is interested in knwing relevant transprt netwrk resurce infrmatin, especially in light f DC 16

17 intercnnectin. Initially, the DC cntrller must negtiate with the NPC t identify the set f endpints it wishes t cnnect. As part f the negtiatin, the DC cntrller may als express traffic characteristics that need t be supprted between a set f endpints such as traffic demand (i.e., bandwidth), and QS requirements assciated with DC endpint interface pairs. T allw negtiatin t take place, the crrespndence between DC endpint interface identifiers (DC EPIDs) and prvider netwrk endpint interface identifiers (PN EPIDs) must be established. This may be accmplished using a manual prcess (e.g., exchanging identifiers between DC peratins and PN peratins persnnel), r it may be autmated, e.g., using LLDP 5 t exchange endpint identifiers at the user-netwrk interfaces [UNIs]). If the endpint interfaces are under the cntrl f OpenFlw SDN, this exchange can be dne using PACKET_OUT and PACKET_IN messages. By this exchange, bth the DC cntrller and the NPC can acquire the assciatin between the DC EPID and the PN EPID. Usage f prtcls such as LLDP r OF requires sme authenticatin f the exchanged infrmatin r f the endpints exchanging the infrmatin Negtiatin respnse During virtual netwrk service negtiatin with the DC cntrller, the NPC is the actr fr creating a respnse t the DC cntrller with an assciated VN. If the DC endpints are identified in the CVNI using the DC EPID, the NPC must translate each f these t the assciated PN EPID befre prceeding t prcess the request. If the endpints are identified by the DC cntrller using the ID pair (DC EPID, PN EPID), the NPC need nt access a translatin service and can prcess the request using its wn identifier frm each ID pair. The NPC prvides a virtual netwrk (VN) in respnse t the DC cntrller. The granularity f the VN has been pre-negtiated by the mutual business cntract and plicy and is expressed in terms f virtual netwrk elements (VNEs) and virtual links and their identifiers. See the frmal definitin f VNE and virtual link. In rder t prvide a relevant VN, the NPC initiates a request t the virtual netwrk cmputatin entity f the NPC and determines the feasibility f the request. The crrespnding result will need t be sent by the NPC t the DC cntrller. The algrithm t cmpute a virtual netwrk is ut f scpe. The implementatin f the virtual netwrk cmputatin entity within the NP cntrller is als ut f scpe Negtiatin initiatin/respnse infrmatin The fllwing elements and assciated parameters shuld be supprted at a minimum in the VNS negtiatin initiatin/respnse: VNS instance identifier. This identifier identifies this particular instance f VNS. Traffic matrix element. This element describes traffic demand and ther QS infrmatin assciated with DC endpint interface pairs (e.g., latency). The cnnectivity type, bandwidth type, and directinality are a part f the traffic matrix element. Cnnectivity type:! Pint-t-pint! Pint-t-multipint (future cnsideratin)! Multipint-t-multipint (aka anycast ) (future cnsideratin)! Rted multipint (future cnsideratin) Bandwidth type:! Cmmitted bandwidth resurces! Excess bandwidth resurces/shared pl (future cnsideratin)! Others (future cnsideratin) 17

18 Directinality f each cnnectivity type:! Unidirectinal! Bidirectinal Lcatin infrmatin element. This element describes the DC endpint interfaces assciated with the cnnectivity element. Fr unidirectinal cnnectivity, the surce list and the destinatin list need t be distinguished. VN descriptin element. This element describes the VNEs and virtual links and their identifiers that belng t the VN Virtual netwrk creatin Fllwing negtiatin f the virtual netwrk service, the NPC allcates netwrk resurces needed t fulfill the agreed upn VN. When these resurces have been allcated, the NPC ntifies the DC cntrller f the availability f the VN fr transprt f infrmatin between DC endpints. The resurces in the netwrk path in the subnetwrk (e.g., crss-cnnect resurces) are nly allcated when the VNE cnnectin setup is perfrmed, which is described in the subsequent sectin Virtual Netwrk Cnnectin When the DC cntrller receives a service request frm ne f its business applicatins r frm its netwrk engineering functin, the DC cntrller s path cmputatin functin cmputes a path thrugh the virtual netwrk based n the VNS establishment prcess. After path cmputatin, the DC cntrller will issue VNE cnnectin setup cmmands and send these cmmands via the CVNI t the NPC Cnnectin cmmand The actr f the VNE cnnectin cmmand is the DC cntrller. The DCC sends a VNE cnnectin setup cmmand t each VNE in the path cmputed by the DCC s path cmputatin functin. Each VNE sets up the cnnectin in the NE r in the subnetwrk represented by the VNE. The DC cntrller is in full cntrl f the path thrugh its VNEs and virtual links/tunnels. When sending VNE cnnectin cmmands t each VNE, it is the DCC s respnsibility t prvide them with relevant parameters. Any change f existing active VNE cnnectins, such as bandwidth mdificatin, shuld als be supprted. There may be bandwidth mdificatin r ther changes t the VN state (e.g., capacity, delay, etc.) that fall utside the cnstraints f the existing virtual netwrk service agreement and wuld necessitate a renegtiated agreement. It is expected that renegtiatin will be dne based n the same VNS instance with the mdified attributes. The renegtiatin f a cmpletely new VN is fr a future cnsideratin Cnnectin cnfirmatin The actr f the VNE cnnectin cnfirmatin prcess is the NPC. Upn the receipt f a VNE cnnectin setup cmmand frm the DC cntrller, the cmmand is either cnverted int a cmmand t set up the cnnectin in the NE represented by the VNE, r the NPC s path cmputatin functin is triggered n a VNE representing a subnetwrk t cmpute a path thrugh this subnetwrk that wuld cmply with the VNE cnnectin setup cmmand. Fllwing path cmputatin n each VNE, the NPC is respnsible fr the setup f a cnnectin in each NE within the cmputed path f a subnetwrk in the prvider netwrk. In sme cases, the VNE cnnectin setup cmmand cannt be cmpleted successfully. A subnetwrk utage, fr example, may cause a setup cmmand t fail due t insufficient bandwidth. The failure respnse shuld include enugh infrmatin t permit the client t evaluate alternatives and pssibly initiate new VNE cnnectin cmmands. This recvery actin shuld be dne within the cnstraints f the 18

19 established SLA. Any recvery actin beynd the SLA level may necessitate renegtiatin f the virtual netwrk service agreement by the user and service prvider. Multiple pre-negtiated plicies may exist between NPC and DC cntrllers, their terms depending n the virtual netwrk service cntract and the relatinship f the NPC and DC administrative authrities. Fr example, in the case that the NPC and the DC cntrller are perated by the same service prvider, mre detailed infrmatin n the virtual netwrk may be prvided by the NPC. On the ther hand, when the NPC and the DC cntrller belng t different administrative entities, hiding netwrk details and additinal security measurement are necessary t prtect the netwrk frm ptential attacks Cnnectin infrmatin The CVNI shuld supprt VNE cnnectin setup, mdify, and tear-dwn cmmands and cnfirmatin mechanisms. The fllwing elements and their assciated parameters shuld be supprted at a minimum level: VNE identifier. This identifier identifies the VNE. VNE cnnectin descriptin element. This element describes the cnnectivity type, bandwidth type, directinality, and ther parameters fr the VNE. Cnnectivity type:! Pint-t-pint! Pint-t-multipint (future cnsideratin)! Multipint-t-multipint (aka anycast ) (future cnsideratin)! Rted multipint (future cnsideratin) Bandwidth:! Cmmitted bandwidth resurces! Excess bandwidth resurces/shared pl (future cnsideratin)! Others (future cnsideratin) Directinality f each cnnectivity type:! Unidirectinal! Bidirectinal Lcatin infrmatin element. This element describes the VNE cnnectin endpint interfaces (e.g., virtual links, physical links, lgical prts) assciated with the VNE cnnectin. Fr unidirectinal VNE cnnectins, the surce list and the destinatin list need t be distinguished. Fr rted multipint VNE cnnectins, the rt, leaf, and leaf grup prts need t be distinguished. Prtectin/restratin element. This element describes diversity criteria requested/applied fr each VNE cnnectin; e.g., diversity requirements relative t ther VNE cnnectins. Service duratin element. This element specifies the VNE cnnectin duratin in terms f begin time and end time. This element is ptinal; if nt present, the end time is undetermined and the begin time is immediately Fault Mnitring, Detectin, and Recvery Fault mnitring infrmatin can als be exchanged between the DC cntrller and the NPC. This functin culd be cmplementary t SLA management; it is related t fault and perfrmance ntificatins t the NPC with cnsequent actins. 19

20 We have t cnsider tw types f faults: ne assciated with the VN resurces degrading r failing (partially r entirely), and the ther with faults in virtual netwrk cnnectins. If a virtual link is prtected r restrable as part f the SLA, then the NPC may hld ff any failure/degradatin reprt t the DC cntrller while it is prtecting/restring the virtual link. Examples f fault r perfrmance issues affecting SLA may include: An irrecverable fault has ccurred in the ptical transprt netwrk. This culd be due t a variety f reasns, such as ptical transprt netwrk prtectin/restratin is ineffective due t an unmanaged failure in the backup facility r insufficient/pre-empted resurces, r the peratr did nt deply survivability mechanisms. The ptical transprt fr the DCI cnnectin still exists, but the service is degraded. Fr example, guaranteed bandwidth cannt be satisfied, required latency cannt be satisfied (may be augmented with current latency value), an increase in BER/EBR ccurs, etc. Respnses t fault and perfrmance ntificatins may include: The netwrk prvider cntrller, based upn assciated netwrk peratr plicies, determines t take apprpriate cnsequent actins within the ptical transprt netwrk (n a case-by-case basis). The netwrk prvider cntrller triggers executin (thrugh DC cntrller) f apprpriate cnsequent actin plicies fr clients/custmers. 4.3 BENEFITS This use case prvides many benefits fr bth DC peratrs and service prviders. Such benefits include imprving ptical transprt netwrk cntrl and management flexibility (fr example, the ability t deply third-party client management/cntrl systems), and the develpment f new service fferings by netwrk virtualizatin. The CVNI enables prgrammatic and virtual cntrl f ptical transprt netwrks by allwing applicatins t have greater visibility f and cntrl ver cnnectins carrying their data, and the mnitring and prtectin f these cnnectins, subject t peratr plicy. 5 Use Case 4: Packet-Optical Integratin The gal f this use case is t shw integratin f packet and ptical netwrk cntrl. Such integratin supprts jint ptimizatin fr greater efficiency and takes advantage f knwledge f tplgies and status acrss layers, as well as dynamic capabilities supprted by the ptical transprt netwrk. 5.1 ENVIRONMENT One example f packet and ptical netwrk interperatin is a cnnectinless IP netwrk running packets ver an L0/L1 transprt netwrk (e.g., OTN), as shwn in Figure 7. The IP netwrk makes use f L0/L1 links cnnecting its ruters and runs IP ruting prtcls based n the Layer 3 tplgy. 20

21 IP Packet Netwrk Wavelength, ODU Wavelength, ODU Optical NE Optical NE Optical Transprt Netwrk Optical NE Figure 7 Example f packet and ptical netwrks The typical cntrl framewrk fr this is independent cntrl f IP and f ptical transprt. The ptical transprt netwrk manager and IP netwrk manager are separate, as shwn in Figure 8. Traffic engineering/path cmputatin is dne in the IP packet dmain withut knwledge r taking advantage f the ptical transprt netwrk s current tplgy and hw it maps t the packet tplgy. Cut-thrugh paths (i.e., bypassing the packet netwrk) that may be available using the ptical transprt netwrk directly may nt be used even if they have lwer latency and are mre efficient. Bth layers implement distributed cntrl planes fr frwarding cntrl withut multi-layer crdinatin/integratin, making ptimized resurce utilizatin a significant challenge. The ptical transprt and packet netwrks may in sme cases have limited interactin facilitated by a cntrl plane UNI interface between IP and ptical netwrk elements. This requires implementatin f an ptical UNI (such as the GMPLS r OIF UNI) between ruter and ptical switch supprting cnnectin requests r exchange f infrmatin between the packet and ptical transprt layers. The UNI has limited functinality, as it des nt supprt exchange f tplgy r resurce status infrmatin fr path cmputatin, nr glbal ptimizatin and cntrl. Figure 8 Independent peratin f packet and ptical netwrks A different example f packet and ptical intercnnectin is shwn in Figure 9, where the ptical transprt netwrk supprts cnverged packet and ptical functins, and a packetized transprt mechanism such as MPLS-TP is used within the ptical transprt netwrk fr mre efficient aggregatin and frwarding f IP traffic frm the ruters. Figure 9 shws the ptical NE taking incming packets and allcating them t different MPLS-TP LSPs, which then are mapped int OTN cnnectins taking a direct r lnger path depending n packet characteristics such as address r class f service. 21