From 2eec42d0ef13ade6e1e6e50a34f27a90145e5840 Mon Sep 17 00:00:00 2001 From: "Lovett, Trevor (tl2972)" Date: Thu, 20 Sep 2018 12:52:57 -0500 Subject: [PATCH] VNFRQTS - Updating monitor reqt for Casablanca Change-Id: I0edd6df398a233d7efcdbd6341eec1e9bab64a49 Issue-ID: VNFRQTS-278 Signed-off-by: Lovett, Trevor (tl2972) --- docs/Bulk_Data_Transfer_Mechv1.PNG | Bin 0 -> 12968 bytes docs/Chapter7/Monitoring-And-Management.rst | 836 +++++++++++++++++----------- docs/data/needs.json | 523 ++++++++++++++++- 3 files changed, 1016 insertions(+), 343 deletions(-) create mode 100644 docs/Bulk_Data_Transfer_Mechv1.PNG diff --git a/docs/Bulk_Data_Transfer_Mechv1.PNG b/docs/Bulk_Data_Transfer_Mechv1.PNG new file mode 100644 index 0000000000000000000000000000000000000000..f97ce161d508b08895ceb3b7637de16440c23f7b GIT binary patch literal 12968 zcmd^mdpy(q|M#k^T&0jgC1E*q!i6H|u!R)qK*sDUImc>F&9Spn(o}?yLnv*+W;Tai zofvWo8|F|M!)(~bV#fW^)z$a<-S_Xm`@SEK`|-H{*u&nR_xtmHz248)`SqTJ(+)OU zHtpI30)e*J*+R~MKx=rw=fdwBfF~vLF&BV8Yl6?%Sb=bDyC;CbZ$6f%EJ2|16v?HF z>w)pctG2GeAduAi)z6wnWXWX^NYBg;VtMYm2Pa#y+WmYq@x1To0_c&vWZ;WG*?XUY z>_km3o~$MO>2&jI0%FQVM&?b4-2G!#m-0)FSy&!EwpqdN_wyw69lw9wb!#h17XwPz z_?xWCy&E_0FdyEylWGnhUJ4tFb@$0V65N(iDg5M7IV?oSv`@A4N6t@GdJnkj>|Cv`6|d5L7G;U+E=RWDZ#F%FQ`59N^&71ABe){ zHm^NabAzgSf?LCiA)@*+pTDu?n2MQ_L9?DIF703teqH?T{L3@X-*Ry;h3mbb{x;TI zccp@E%&);%KQ`s@(Riw2d|TgO_@J9v5~xE;1r?u~yTsD6blRW9(g{v6#lJb+$=;G3 z2P26bAW|I;s|&*G*lq-Y_?A%3BD^BsVS055-jg$v~{cIaM$fc-YQbtSgPh&bugJ(zXJa(-_3 z(mBEXT@^adM(bccRZItgX5X*!@H?FSNYl|FErZH&diqz=J`{`z;;aY9?b~lfCx4Z6 zXVY=;tdLTGK@j>jAOy9thlMaLl-Y@IFmHYc7TAC0!M%NcUi64v2&R9s$jcX?IkZYM zM#kF&&{;sP2~4@v?ciyn1JWSQx@livDj<6G*dPF=4nn;Wus0w<2yc_!CX8_R6Nwx1 zH^UD@Hp1DAJm`<9LJK&X3_s~L<$-*kCS--_29`!&n2Ni|TMKACz$>QKDs>V|RTOJ# zE>FLV>oAU`^dlD0Q3Cz4`Lkuo9r4uj|3E38fDx6i&c1kUqs516mj@scW5%KED;{04 zZ(7}2OtesWq5U2$Vh&c~uPUPQqw?Ns-M8g`NF{YS44Y*;w@=`!M=uyYGe0`jGTd0j zZ`qZZUKo9Hi2!5vrzp9Z{YQi^>*L)^UaJLMn!Ae&m3Ny?a!-lb*?Q0q;}*a`zC8%m zLOmhOp%Vsj6hZy#R>kZZf|WEokplpmTF&%uiHgFAv;rC0S}0EA7^mgN8$Sdy!aR!> z!;>}oN6RjE6117meVy6*#AotG$07lvJ<+`6 z#`a6ti@JgOM+5rdOx1*g(OXHsbooA7SXNcvuH}o%+7rx=|4h3hhyzOYy7zq2fK4;YUN?l!#8q> zZrS?gc^hUOrrIiL_w(9S8}$ysW?et^;hvb9L>W-y>U7Pgq6@&&*bj0LsnZ@m74KXc zn23nxyA8>fH}yia)KI4w1%KQ$1oP@`{|n7lvOoNiRPtRnH6J(aoA%wXvG6+Kd1myJ zf6;>zxPTBdg`L40w~;#ZC`olXU?k+*rk|%?)!+k;m|~r)+cbO-%mbcUpn9-I@8Fk%dl~0Pu+OOPNzC$?8)rVv)W%PklCmaeY z&JLRdGnK*zI_rdW)1k3560sd#Xh*>RkFE!7XjPDMPE6uZM5)QxQ%_kx`)-LC!Jk4T zV(FEl{-h$8XRlf97DRq8_WiuwaMZ@))L6Ti$RC*5W>XChk4Erd%QMm|Z_f4-J}Y2K zO@BJMOXDy^)s+krK?lW=DSlaya&4G0H!Z|1-gAs zUT%yPG}=j;hTIo7wJSfJUj8~08!{autWlKzkDisl*@&fY3WIGX(^K5c2*k|yibOJF zn9mg+R{Q0=Tl+jFeft_}=SgGaYyol2M;El z`zri<4hTC__KXh+>(_84(obE3~K(DrSQsD7Arcm=>pnY3I7&SPI>ey*jMaoZw|I{(mmnFbH(geG*)N!w4B zU;4Po@Z!5WOoe_tmdu`ee`w;`#03a0IEB(@v3G`9r3c@s+>bm2rgPAusY>MB zp|!_MRzv()yW8oruj-Nu16B$lE@b-|`N4wd9yz+&$W$FV2Ov$?LvoiUU4Od~wi-NY z`E4fLcajb3y?PRXoX9SUNn*LQtAOy5tMNn_SDJKvxm`ixMbFd+6`nF&|6?|KETc#N zcMxYSIIaX8+(Kj0y9MnKE1th|;vtkcm!CuleaV<_i*;$=1;TFwc46^abi%il<&1m4 zD%&{qqCMQFj!J9;?C>|K-dNkNqEHJGq@FoDD(-hI>dG~z)sYso3?sUI4a2zulYMJ% zgssD@yL@BWE(tQ!ymDI#H2NDb27x7RINzkM(E|a&vh)}ewDSga&GYksyW9*6Iu6Jf z9oqn;c)oJ+yH(Z!0R_JaBK2?$5KLj~!4gy;-h;3}OpJ|R1rI`Tp{35) z6Gdx4Jb?ehHz4A-(lH&$$`(Vd8TyT8vmdr4P?2?Ww99>>;guL-7^mOg4|HP*ILsDQ zCsaY5CpFsZnSxDQ3!*9jdamOCM0)qpKlbr5^nIM|*MOLkV2N>wJm-a+NbW>cAj4T} z4d@{dN1iL+fsLk`fR0rHJBdFapG;SeJaA`j0G$HzW5G7c`8H?}sN>2iTo+28B@KX{ z_pM@hx-@Dl`X6N>$9Gd)OopLB7X%E8L zEE3eA4Op%`#KXeaLTF)1u^-cdo%#1;;3&I)uK0icYnpdLRMXjmk60DGJj5rrZZDEv z;NmB3#(~D%qqV_xMO|!uVvaQ6LM#Amq4}FO9%9?pYxp*aniJ?@4$~rxW%lUF@AaPu z%K@wu?lXFoY9DLsD!KrA_LUIropH=8c~U;A>JYv@qjP~YF=k?{9wQQn2Jki9(i}6E z!Ij=G&Sf6(Y|os9p;qJ|nLz$65inR^zci{?TOi=!OR(p0euR24?Ye$t*kD7O=knx& z=fHgtE2M4s>iaECak~6ZhI(bM-H5nF?K@z=v%my5Wm7MB=;mcTOFD#tHs;AMm{smM z1!EFV)|mKVkc=uVqu9kioF$XcW058nfbkZ3_!(`NSgmiaU=G%oSc8Q%H1UKpq|tA1 zQoezjM{$qj5VBEmmsWSrR7W8i<{JJAfKPcVH13D7%G&kgck_-7PMtpV^VnP2q(ib* zX>Kkx%3Aiw=`z;5e*8}OOi{#(ps;;Xt57QMQ@x4dSTY|T*`?@GcjbeGMk^}&VC36nQ$O3lk)zJVpSdXDggX3ObykGnD|IZf_HFyNJ!G?6= z0Ra1d5ZfTN`zbZ?PGyUB4H!k;4j{J?99MPGv(ej7gn0)1alpOoF-J<83P^Sugp0v=KRIPPI8V}##=m0tjq?YDG={qegOB|VuR z*I}#~Di{j^_1*Kocx{}nX?yZ+WJXx{)#%mtEP(e;uD*w?BlNVc^rS+ZTift8RX{G8 zHwSIfFO4~C<_3z6`$2e(-mP-$ee1gUfV}_f_Zxpd2bf!<_wVojZ>`V!WB0WWTe%$K zaF}(RROtJATatnzs1H@St%k!_eBFvN9(ZL&OXVs0ofAW1ik|F2VYV$-N8dBd^Yv-ePa`i#y%UPu``Ue1n?z$A>=XPG%WXzi?ofO& z9VE3-@i|Z3nD>=Z_3lLEAORzF`~>!ydiZ#C6KlFL#BmDF{yB^A#aIgfS}r?G)VzM5 zGo=9LmGczZ)~mYTx`efG4;KmyYiK+Fo*nK0$Bie{1!Vt2YIO+zhZ15O1`J8RX1Dw| zjQor8&(-jYe{;43)IPvDc~Tm~FGnB)a||On%N9;{S&3CkRVG;TCa8;U7v0WEwE!!hS*Y-!Sqo z%0E~CLhJ`7q+gJ2SOxSD>L1D>SYS9r_y^Ft@~hI&Lj4lfDuS;6Ac*|$5bXU0{}18x z{-Okw-v6s`{wGHMMfvCIUx@v{Bt$(aa|8IIG-rqhXB;c)$ zIQXtxjE4G|{nxMCpp*>hA?qs$xA?vRvYu0V(*rgem{>ahX=;bgOq>axJ{Lt;=7`D}O>8LO31|bds z&+wihTjKBCuYRMS+p%gG?DOo@DxGVvk-~BG_pfn}0*vbCut@beI%?orqdKCbYv<9c zf2JD`ot^LV8U7N}c9j1~yFDCWT%++VG>=gb-2FS?tZpB;R)SJ6BagQ>NXbPXyW70= z^Xo!rbhoBCrj{aDr~RrxLK$VNXW=in8?q5xG|dwQuvQ4|&Z>)>HY00Mo8c z!m1|Nw=Pj}T8Yn4FcSQ^6^f1r*k#NvbLit$;gH4xH(DB%9 z8mkM5ZU2`C?kz)f?$UIHU;_t>wXU(FRb3~Xu-z|L59hYEpCMO{;h;l?mI@imk}Hd4 zLBr9)Q!&ah-)FvZYlg)^=dfXbj&!+Tl&}7^rb%M=MjMu9$dIjW!L>gL`;O#bY4aB1 zuFiyNpYyQis%T8VYvsJUa3ptVs?A7PYF7%sM4x%DMI1OYevq5hPcX;#XIsAOT)0`^ zMaP9^v*(m3dynMvw;3Y~k2(c7jnt8wBg^W94zS1J?X~neu>;grt@1T`Rz3WE?8&gk zEsAMTcAsbN)E}1PSP+j8pluSq;_;p9alhGX zhuWuWmHqCc=y#@Q=$Z}hg`HNYowz{}c?e>!gi+WRU#lyFuCio)Oi;@!eSN;MhquRU z(TWLwXgj&$^C6z;fexjx^WSw0zuD>MPd8S64kT`hw{de<3iy@YoECTmW+i>7yM*lw zXZbHgbAyY?uF|bi&3EwTWk~eii5Pl1R@M5R8lpCH5a_dbJRe`WGSxevK7EA&lpm)h zVa&ecET6G;l<`l4(x0vck7;kpu}=*=JddSi|AxcyU1-RwZU-w=u3hf*Od8z(M8|{N ziu}}DeyT=sJ;1%OMWwQ9cShVE*Kv8X`qvTj&*kGy8RJVQDL!H8pE4^|u4~&Fbeer? z+!OAuH!m(w)TqI(oZq@G!GMCkhE=p!R?N0)ues|$kGPr74_6H>WG7>w_loCb!P0%#J;AF$~!R7Z$}$9+S@l4y3|scn-}8ltBmcILKHN z(hbhy3CSgFbDX)~@M|2tgMw-!H7Q9fnu$(Fk2}hsZ{DIRuEY2!LUNFYrD8fPB}jao z9is+y^&jiz=1mIK(5MN$@R_%9Y6^PZMlq|L0Wa*mhnw^3^3iAy=vArGp3F_yE` z`8G7ZR$M@%mpAUoinj9UB^0lzPeJMskA- zbapGcyA;*Z%7N|$P2qsi!3*ILie#GP_Uzo((E8yR(RmiRfW_V-yYSkz@>MW{$Y*tp z8_f;0f*Ww58%@-B(H44CEwsOvULad6KD^hsK0hI8Jmirc2;ar>Q1?xLT`&jle=j|&!Qz(%E7s-*WYN* zZHKH{%4MK|-UWVn55i6AM<5HKLGR`}BiN|29xy#dZRNF}CZ-h1P4|O_#4PUR;kRRt zXkA<6ojZ)QqT|)rWiEL0y6j8s1y2i)aAGZIQmjWgMuLyW*y7NbzUAY>IOULzx7?R< z2L~0A=gmv@w(G2ovA>!`6>5yhi)_sHl9_f9-k@v!ez7Am%8r+z88>|_9G z9?8aAV1>jkJvSdO&V@tE=9gOUlxmRAI$G?#P&|1TH@6nb(hR@|i=bR${u6v*7nmqd znjuOim=5~4TQkc;u)^ca%=z~8F>zq#Rx@NQBuMLO7LkTm%apHZz6WE(sP#Ska;l#8 zZoZ{3#nQ=@k)G3~^XLV&$1I}vVq8sJ>}(0+%)-^6I9u|g1Gi}S1RBlHqf?Oh$~`b! zIaXPNC*TR@C!#0N^5^bg{i5yOOoTP}A(j&rSFo|tG%Re@a>tkOR!lR(<1R4W9J@ZK zCD7wLIDICNT+H%&yaUG6g|dn*z%F=cvlD3=NHc%Z$L3e}$JEcdjTNVjM=xZ43ZyLa zVdokYNNE$DX+G*aUC)MUU4-&<)e?^Pc0i*O4KL^2y$q9e_yC8eQ$wAgB|YekG@XE0 z1@*0Ap$jFQau}B)0=B9XPh+6e7b2aD8(|iiJ@qXnz*r5n5nntv4^>fmR92m$AzfEbG%oetXXm<&2-IZH#rmKTvtH8VyAs*tA;O$hA2WMCXd<|5Jv&nw#$2D+CJmkjZtW_Q z+ZiS%(uUqEcP_y%P44v(a3=68AJx*-g6ImTlR!0l$$M3&zoRVEPKC2#dc68lSf!4M%Qd{=b z&of`hdOl3FLUpChgW%xwy2+RYK?JefGx!a6HD1V|Jr7qxac&Lxx--*_uq8$-%xOB5 z0b2|s4jpfF1A@bTa(wGDcM+p7Ctuhy1!U<#gNsr`Kl@SZrw=#t#2Z~|wpm0*fKj6f zPZY^LCNIu`T_n|`HA$8t{K}C7JbBd&uSvm9 zu4kNb-+tbDM{GFTpmqowllCeA4yMPIt*B1pXFCpuZIbjXBTU0?!KCj+;o&Bx7a+s(OzR^--H zSMLGQG1S|v1ow^b@3b&2RKR>$D}P?Y1Jqkom);13VLN({Ts$xy{5DT#ZJ{lP!t{ z=h`omI@ndgGO`hsFlHX-T*}gDDp5^QmNbUN^+iygK^X@#9q4wYWf~|qt_`D5*q1(j zJ$wlfJD_edby&sK;oZU)35)R|!#|JBynp)eIDaGy8E&(C;iWd%rPMSUiFOOavaL^c z#$~VEERu$Z9#)R}VMNF_Z+m#V-`ZhxI-I<_1?X(Mnk9`w%7!hJ>pQa4Q9W@XNv2w- z9=+D_jWiFibUTdn3XFudY(K?VUJ9-Hgy7n=myT@0vQLFv!BcB&h-nM47G5)7-Ub1s zTaz4T-GNXZ=?EoM(PKqPHG`SD5}qNNVzqHKc*D5q{<@(mID7s$KRtsQSZ5BnW@J^Z zc>L-7_bv;zY1rrBZrKQ+$f-FunUl}4Vo{2}BS3*3q0};cSkYqP1=mRP*5dW-^vdt4 z&S=Ug)=#TclebK}sHEe`9IRvn)r8Val2aUW&Ffkg*GU^w2Uj|teKArm#5`MEs2o^7 zTwM#)f|P-|wuCC6cRGKM?{>PLI;UD9{V_kG);Y=DuB& z985+I3H?WRH>ACM65$zo(kXlMlK`)f`w@D6az1qe09~`xZIDSWh58Fx}E2X94HK>*mri>{LGv`W;3(x=*@8Dr|Rm?t`SGie3+5f{B;%)>A0Av1s zCRg7Kd%=j2n=ibn<+8*|Qjc329Ih!vJ{vmqjh|i?UV4_oqX8Ck(5uJ1(Cu&W<%Vj|L?UaDoQypFh!Il-XBy~iUH&o|kUCM8V`!W~40SvdY4CDy zMEBDBl%RC-SYY-Of-j=V0xIebepO3BCZ+W)YenoaIUea?=IrJx%gdxeAb-#2pS5S62J&~nfy*I8V+t-WN^M%(af$k79G1uhel~bT zK2Y(%$TWji+%ow+jOCl2UjF_{U}xz!94LiL#OX} zr=a@Uh%rk`mJ8(P#;o%Whu~zqy;0!7r3%97o$x%iXXBZG6&Lqw&~$Xt{7AbYZ@sDx zrd0h)JNuID;QEUScCe+S{YP?#+Gss6?y#%Vo$(_oyk#3bdfll0^a?2wZ9RIM{1+({ z24yz7eAsazoJ&7&>Gf-2y5CT&^dS!zCL%PukW*GU+E1al>lw_7TF%iBMPff!@bska zVprk=n?}E`<@vbYWDD_h!O z4CTYP1zs8~a*AelDe!Obb1jKG^x(wl~vdDkdl? zEu-T|cK!NKce3jPtVEVfj$+SfiqfJm=yOU@b-KY7)l*dSC>JQF)aE8!Qn)9?tsDImW8Z!gUMZcq?#G+-+bP~C*^+$ORXnD3uVo( zU+VG|2_no~>H_cNxDE2>=5ysq7Q?@zJqSUA6A_QM6F#YBXa_j;2_m*t)A}MfjjLrq z?{)-pzP5fTu8M>>eFB^FA9Nn*$@zqP;&f z0f~#!g!d;``R&A9gjwZKXzkEkSY^oHr7Ctisj3o1pvA#H$r6>~XohY~bQSefPW@49 zFuk^!219}kH!_y5tjv$6(+kr4Vl%76uU@b0I@bVWYD7zdb({q^m-vl2_Ayh|SpNDH zop2pz^8q^})ce?>Z_B(g^Qi`psPm`$C&s^33Cu?FRCsG&^Z~h->q+u*g`hrQqs!#@7ivVO~8K{LCi`eeSc>%4Z`)Fke9@IN$(S<=Szrs~e+oEk!l4l*yv!Z>*i* zCE=kF*j0$AU>!ZqA)fPZ7(+v{;q}hMxu9j9%eK5+GgK5<;F+S#<&u$Mr?(eAC4GAp zFz{R~WefWfy|p?>r|bIl#oRoBK?wFo@2#H{P$y@}#3n2^;$fHPzv3d3q`$M*ZPRs+ z==+WMoqljI)8)WBmAlR2N*3vnquG0L6F0Kj)8RYIW6)u&5%zU1NQb>2INEl|&<>!+ z*#btw4XzA4yPvXXmA=DaX=);fD4fm-p*z%aj|-;9o;KZUY^96O?GKk3%Bfe zXbXpvQpAgWiS8bnMy&e2;6bWnLv_kj_%S`fwPsfqId{mctYx^^urnQxFt0QJ-tM>y zxOrH=35?uKrU9(#I0!D5%?4BM;y!uQYGBA@RL_}o_xh+dG`B5MdDDq_ff*$xEII4? z;AO+850q-*biK`I-ttnq_INOz^zpa)#nDr5DWS1eNwq(Up(InFW%muLVELkEKy0h+ zld?Pg{!5Cm&V+P(Wxk_u?m9ydc`Fq>Sdg@OrB%Pxgk?6J)Tc! z!pY$F;r%v)q#sw`Q#bk;KxiXn%*izAK^0&2yL>{f21qGBfl? zngk>%4hX3EpMTw8x<9%a*5~B{+2eO|(*Gqg{p5vXX3$iZgB~N?ISA5;SO>{$n>!oi z0AVoPQGL?4L{38DN)!Qt)zL8K9`ee5@BtfK8X)g+omAk(oA2tz&D~rl5w`G`3cNu2 zG-N1zv7eCBmPyd5$&g;k&#I+P-=>Zvk%vQjY8twGE={HMcIkGybqDHTiV9+7!JYF4 zWP~|hIW$((o?cwig{kgo$qO#gMZ)p4PeJ^l!k1dS!;AAre_XReV}LwUKROUoe4836 z1x~R@P5FRBY&~mOYj@(7V@v7l&R8Y;HoH-$Z-CV#)EKUuz(28Mt_OM!J0Ur-GU&+T z7N!N@3P*kstgLYkRha)}_MB0f=ZM;pS?T zpKjZ}qi+wyBWFBp{~!^UM9hI#>XJ4w)R0=V9S~%G)gFl^SQ*qzHX?8`oBECAl=Lu- zNL7xweDU<3mm_7+?E)gSK1RGj*r6k@RssHMTF-p>g|v4x5%$WzoF*IXf(cTHF`ht~ zspF-ghyzO~RVVg^B!ir68`uFJaj1WCY{lOWd{DOS?_2)UNy~}PWKyHmI!~+h)k6@w ztV9V|kx4rqAE2Zn88Hc4ZHvxm-#qO)TKLFe@{9w6exUMCOQAMPFrS$AqGhXO|TLb*xvx@#M*hD;>`*;dkmTeN1daO;jWnD#09nS4IB@+_oMD zqdr~^;-?~!u(o~&FLhx@%vK}S!i?2R;9?@2JuynFsG?OBSr3j+l-vy(UGkFzYu-7m zzj^_>D-d%~V;bKbpgy=sn(*yNnO;mpzmDpi!@zGAJG)L|><3~37$0z)z@1tsD_i{^ zx99pbwDTIwpnHFT-_vowb3Ox z02}w)$l&-8ehVCA(<*G3cOH8GxLqF#!xnElP+HiMF(sY|QHy*;gyamx4PVl{^YGB> z9c6K`ypif1d@yj0FAcE$*l6|YOVCXKPS4rBdJF#ZrwI0U+75S})Q4A1to}xF(XZF= j|J46e online) Other use cases include + notification of file ready for collection using Bulk Data Transfer or + notification on configuration changes to a device. + + * ``Other`` - the Other Record defines fields for events that do not have a + defined domain but are needed to be collected and sent to DCAE. This + record provides a mechanism to convey a complex set of fields (possibly + nested or opaque) and is purely intended to address miscellaneous needs + such as addressing time-to-market considerations or other proof-of-concept + evaluations. Hence, use of this record type is discouraged and should be + minimized. (Note: the Other domain could be used to create and test new + domain ideas.) + + * ``pnfRegistration`` - the pnfRegistration Record provides a structure for + registration of a physical network function. The pnfRegistration Record can + contain information about attributes related to the physical network function + including serial number, software revision, unit type and vendor name. + + * ``State Change`` - the State Change Record provides a structure for + communicating information about data flow through the xNF. The State + Change Record can contain information about state change related to + physical device that is reported by the xNF. As an example, when cards or + port name of the entity that has changed state. Note: The Notification + Domain can also communicate similar information. + + * ``Syslog`` - the Syslog Record provides a structure for communicating any + type of information that may be logged by the xNF. It can contain + information about system internal events, status, errors, etc. It is + recommended that low volume control or session logs are communicated via a + push mechanism, while other large volume logs should be sent via file + transfer. + + * ``Threshold Crossing Alert`` - the Threshold Crossing Alert (TCA) Record + provides a structure for communicating information about threshold + crossing alerts. It uses data from the Measurement or a similar domain to + watch for a Key Performance Indicator (KPI) threshold that has been + crossed. TCA provides alert definitions and types, actions, events, + timestamps and physical or logical details. + + +Technology Specific Records +~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Technology Independent Records – Heartbeat Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The current version of the data model supports the following technology +specific event records: -The Heartbeat Record provides an optional structure for communicating -information about heartbeat or watchdog signaling events. It can -contain information about service intervals, status information etc. -as required by the heartbeat implementation. + * ``Mobile Flow`` - the Mobile Flow Record provides a structure for + communicating information about data flow through the NF. It can contain + information about connectivity and data flows between serving elements for + mobile service, such as between LTE reference points, etc. -Note: Heartbeat records would only have the Common Event Header block. -An optional heartbeat domain is available if required by the heartbeat -implementation. + * ``Signaling`` - the Signaling Record provides a structure for + communicating information about signaling messages, parameters and + signaling state. It can contain information about data flows for signaling + and controlling multimedia communication sessions such as voice and video + calls. -Technology Independent Records – State Change Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + * ``Voice Quality`` - the Voice Quality Record provides a structure for + communicating information about voice quality statistics including media + connection information, such as transmitted octet and packet counts, + packet loss, packet delay variation, round-trip delay, QoS parameters and + codec selection. -The State Change Record provides a structure for communicating information -about data flow through the VNF. It can contain information about state -change related to physical device that is reported by VNF. As an example, -when cards or port name of the entity that has changed state. + * ``Future Domains`` - the Future Domains Record is a placeholder for + additional technology specific areas of interest that will be defined and + described in the future documents. -Technology Independent Records – Syslog Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Miscellaneous +~~~~~~~~~~~~~ -The Syslog Record provides a structure for communicating any type of -information that may be logged by the VNF. It can contain information -about system internal events, status, errors, etc. +The event specification contains various extensible structures (e.g. hashMap) +that enable event publishers to send information that has not been explicitly +defined. -Technology Independent Records – Threshold Crossing Alert Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.. req:: + :id: R-283988 + :target: VNF + :introduced: casablanca + :validation_mode: in_service + :impacts: dcae + :keyword: MUST NOT + + The VNF, when publishing events, **MUST NOT** send information through + extensible structures if the event specification has explicitly defined + fields for that information. -The Threshold Crossing Alert (TCA) Record provides a structure for -communicating information about threshold crossing alerts. It can -contain alert definitions and types, actions, events, timestamps -and physical or logical details. +.. req:: + :id: R-470963 + :target: VNF + :introduced: casablanca + :validation_mode: in_service + :impacts: dcae + :keyword: MUST + + The VNF, when publishing events, **MUST** leverage camel case to separate + words and acronyms used as keys that will be sent through extensible fields. + When an acronym is used as the key, then only the first letter shall be + capitalized. -Technology Independent Records - VNF Scaling Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.. req:: + :id: R-408813 + :target: VNF + :keyword: MUST + :introduced: casablanca + :validation_mode: none + :impacts: dcae -The VNF Scaling\* (short for measurementForVfScalingFields – -actual name used in JSON specification) Record contains information -about VNF and VNF resource structure and its condition to help in -the management of the resources for purposes of elastic scaling. + The VNF, when publishing events, **MUST** pass all information it is + able to collect even if the information field is identified as optional. + However, if the data cannot be collected, then optional fields can be + omitted. -Technology Independent Records – otherFields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The otherFields Record defines fields for events belonging to the -otherFields domain of the Technology Independent domain enumeration. -This record provides a mechanism to convey a complex set of fields -(possibly nested or opaque) and is purely intended to address -miscellaneous needs such as addressing time-to-market considerations -or other proof-of-concept evaluations. Hence, use of this record -type is discouraged and should be minimized. +Data Structure Specification of the Event Record +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Technology Specific Records – Mobile Flow Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.. req:: + :id: R-520802 + :target: XNF PROVIDER + :keyword: MUST + :introduced: casablanca + :validation_mode: static + :impacts: dcae + + The xNF provider **MUST** provide a YAML file formatted in adherence with + the :doc:`VES Event Registration specification<../../../../vnfsdk/module.git/files/VESEventRegistration_3_0>` + that defines the following information for each event produced by the VNF: + + * ``eventName`` + * Required fields + * Optional fields + * Any special handling to be performed for that event -The Mobile Flow Record provides a structure for communicating -information about data flow through the VNF. It can contain -information about connectivity and data flows between serving -elements for mobile service, such as between LTE reference points, etc. +.. req:: + :id: R-120182 + :target: XNF PROVIDER + :keyword: MUST + :introduced: casablanca + :validation_mode: static + :impacts: dcae -Technology Specific Records – Signaling Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + The xNF provider **MUST** indicate specific conditions that may arise, and + recommend actions that may be taken at specific thresholds, or if specific + conditions repeat within a specified time interval, using the semantics and + syntax described by the :doc:`VES Event Registration specification<../../../../vnfsdk/module.git/files/VESEventRegistration_3_0>`. -The Signaling Record provides a structure for communicating information -about signaling messages, parameters and signaling state. It can -contain information about data flows for signaling and controlling -multimedia communication sessions such as voice and video calls. +**NOTE:** The Service Provider may override xNF provider Event Registrations using +the ONAP SDC Design Studio to finalizes Service Provider engineering rules +for the processing of the xNF events. These changes may modify any of the +following: -Technology Specific Records – Voice Quality Fields -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The Voice Quality Record provides a structure for communicating information -about voice quality statistics including media connection information, -such as transmitted octet and packet counts, packet loss, packet delay -variation, round-trip delay, QoS parameters and codec selection. +* Threshold levels +* Specified actions related to conditions -Technology Specific Records – Future Domains -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The futureDomains Record is a placeholder for additional technology -specific areas of interest that will be defined and described -in the future documents. +.. req:: + :id: R-570134 + :target: XNF + :keyword: MUST + :introduced: casablanca + :validation_mode: in_service + :impacts: dcae + + The events produced by the xNF **MUST** must be compliant with the common + event format defined in the + :doc:`VES Event Listener<../../../../vnfsdk/model.git/docs/files/VESEventListener_7_0_1>` + specification. -Data Structure Specification of the Event Record -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +.. req:: + :id: R-123044 + :target: XNF PROVIDER + :keyword: MUST + :introduced: casablanca + :validation_mode: in_service + :impacts: dcae + + The xNF Provider **MAY** require that specific events, identified by their + ``eventName``, require that certain fields, which are optional in the common + event format, must be present when they are published. -For additional information on the event record formats of the data -structures mentioned above, please refer to `VES Event -Listener `__. Transports and Protocols Supporting Resource Interfaces ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Delivery of data from VNFs to ONAP must use the common transport -mechanisms and protocols for all VNFs as defined in this document. -Transport mechanisms and protocols have been selected to enable both -high volume and moderate volume datasets, as well as asynchronous and -synchronous communications over secure connections. The specified -encoding provides self-documenting content, so data fields can be -changed as needs evolve, while minimizing changes to data delivery. - -The term 'Event Record' is used throughout this document to represent -various forms of telemetry or instrumentation made available by the -VNF including, faults, status events, various other types of VNF -measurements and logs. Headers received by themselves must be used -as heartbeat indicators. Common structures and delivery protocols for -other types of data will be given in future versions of this document -as we get more insight into data volumes and required processing. - -In the following sections, we provide options for encoding, serialization -and data delivery. Agreements between Service Providers and VNF providers -shall determine which encoding, serialization and delivery method to use -for particular data sets. The selected methods must be agreed to prior to -the on-boarding of the VNF into ONAP design studio. - -VNF Telemetry using VES/JSON Model +Transport mechanisms and protocols have been selected to enable both high +volume and moderate volume data sets, as well as asynchronous and synchronous +communications over secure connections. The specified encoding provides +self-documenting content, so data fields can be changed as needs evolve, while +minimizing changes to data delivery. + +.. req:: + :id: R-798933 + :target: XNF + :keyword: SHOULD + :impacts: dcae + :validation_mode: in_service + :introduced: casblanca + + The xNF **SHOULD** deliver event records that fall into the event domains + supported by VES. + +.. req:: + :id: R-821839 + :target: XNF + :keyword: MUST + :impacts: dcae + :validation_mode: in_service + :introduced: casblanca + + The xNF **MUST** deliver event records to ONAP using the common transport + mechanisms and protocols defined in this document. + +The term ‘Event Record’ is used throughout this document to represent various +forms of telemetry or instrumentation made available by the xNFs +including, faults, status events, various other types of xNF measurements +and logs. + +Common structures and delivery protocols for other types of data will be given +in future versions of this document as we gain more insight into data volumes +and required processing. + +In the following sections, we provide options for encoding, serialization and +data delivery. Agreements between Service Providers and xNF providers determine +which encoding, serialization and delivery method to use for particular +data sets. + +.. req:: + :id: R-932071 + :target: XNF + :keyword: MUST + :impacts: dcae + :validation_mode: none + :introduced: casblanca + + The xNF provider **MUST** reach agreement with the Service Provider on + the selected methods for encoding, serialization and data delivery + prior to the on-boarding of the xNF into ONAP SDC Design Studio. + + +xNF Telemetry using VES/JSON Model ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The preferred model for data delivery from a VNF to ONAP DCAE is -the JSON driven model as depicted in Figure 2. +.. req:: + :id: R-659655 + :target: XNF + :keyword: SHOULD + :impacts: dcae + :validation_mode: in_service + :introduced: casablanca + + The xNF **SHOULD** leverage the JSON-driven model, as depicted in Figure 2, + for data delivery unless there are specific performance or operational + concerns agreed upon by the Service Provider that would warrant using an + alternate model. |image1| Figure 2. VES/JSON Driven Model -VNF providers will provide a YAML artifact to the Service Provider -that describes: - -* standard VES/JSON model information elements (key/values) that - the VNF provides -* any additional non-standard (custom) VES/JSON model information - elements (key/values) that the VNF provides +xNF Telemetry using Google Protocol Buffers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Using the semantics and syntax supported by YAML, VNF providers -will indicate specific conditions that may arise, and recommend -actions that should be taken at specific thresholds, or if specific -conditions repeat within a specified time interval. +.. req:: + :id: R-697654 + :target: XNF + :keyword: MAY + :impacts: dcae + :validation_mode: in_service + :introduced: casablanca + + The xNF **MAY** leverage the Google Protocol Buffers (GPB) delivery model + depicted in Figure 3 to support real-time performance management (PM) data. + In this model the VES events are streamed as binary-encoded GBPs over via + TCP sockets -Based on the VNF provider's recommendations, the Service Provider may -create additional YAML artifacts (using ONAP design Studio), which -finalizes Service Provider engineering rules for the processing of -the VNF events. The Service Provider may alter the threshold levels -recommended by the VNF providor, and may modify and more clearly -specify actions that should be taken when specified conditions arise. -The Service Provider-created version of the YAML artifact will be -distributed to ONAP applications by the Design framework. +|image2| -VNF Telemetry using YANG Model -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Figure 3. xNF Telemetry using Google Protocol Buffers -In addition to the JSON driven model described above, a YANG -driven model can also be supported, as depicted in Figure 3. -|image2| +**NOTE:** For high-volume xNF telemetry, native (binary) Google Protocol Buffers +(GPB) is the preferred serialization method. While supporting the GPB +telemetry delivery approach described above, the default delivery method +is the VES/REST JSON based model in DCAE. The purpose of the diagram above +is to illustrate the GPB delivery concept only and not to imply a specific +implementation. -Figure 3. YANG Driven Model - -VNF providers will provide to the Service Provider the following -YANG model artifacts: - -* common IETF YANG modules that support the VNF -* native (VNF provider-supplied) YANG modules that support the VNF -* open (OpenConfig) YANG modules and the following - configuration-related information, including: - - * telemetry configuration and operational state data; such as: - - * sensor paths - * subscription bindings - * path destinations - * delivery frequency - * transport mechanisms - * data encodings - -* a YAML artifact that provides all necessary mapping relationships - between YANG model data types to VES/JSON information elements -* YANG helper or decoder functions that automate the conversion between - YANG model data types to VES/JSON information elements -* OPTIONAL: YANG Telemetry modules in JSON format per RFC 7951 - -Using the semantics and syntax supported by YANG, VNF providers -will indicate specific conditions that may arise, and recommend -actions that should be taken at specific thresholds, or if specific -conditions repeat within a specified time interval. - -Based on the VNF provider's recommendations, the Service Provider may -create additional YAML artifacts (using ONAP design Studio), which -finalizes Service Provider engineering rules for the processing of the -VNF events. The Service Provider may alter the threshold levels recommended -by the VNF provider, and may modify and more clearly specify actions that -should be taken when specified conditions arise. The Service -Provided-created version of the YAML will be distributed to ONAP -applications by the Design framework. - -Note: While supporting the YANG model described above, we are still -leveraging the VES JSON based model in DCAE. The purpose of the -diagram above is to illustrate the concept only and not to imply a -specific implementation. - -VNF Telemetry using Google Protocol Buffers -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For additional information and uses cases for Real Time Performance +Management and High Volume Stream Data Collection, please refer to the +`5G - Real Time PM and High Volume Stream Data Collection ONAP Development `__ +Wiki page. -In addition to the data delivery models described above, support for -delivery of VNF telemetry using Google Protocol Buffers (GPB) can -also be supported, as depicted in Figure 4. +Bulk Telemetry Transmission +~~~~~~~~~~~~~~~~~~~~~~~~~~~ -VNF providers will provide to the Service Provider the additional -following artifacts to support the delivery of VNF telemetry to DCAE -via the open-source gRPC mechanism using Google's Protocol Buffers: +.. req:: + :id: R-908291 + :target: XNF + :keyword: MAY + :introduced: casablanca + :impacts: dcae, dmaap + :validation_mode: in_service -* the YANG model artifacts described in support of the - "VNF Telemetry using YANG Model" -* valid definition file(s) for all GPB / KV-GPB encoded messages -* valid definition file(s) for all gRPC services -* gRPC method parameters and return types specified as Protocol - Buffers messages + The XNF **MAY** leverage bulk xNF telemetry transmission mechanism, as + depicted in Figure 4, in instances where other transmission methods are not + practical or advisable. |image3| -Figure 4. Protocol Buffers Driven Model +Figure 4. xNF Telemetry using Bulk Transmission -Note: if Google Protocol Buffers are employed for delivery of VNF -telemetry, Key-Value Google Protocol Buffers (KV-GPB) is the -preferred serialization method. Details of specifications and -versioning corresponding to a release can be found at: -`VES Event Listener `__. +**NOTE:** An optional VES mapper micro-service can be leveraged to to extract +measurements and publish them as VES events. -Note: While supporting the VNF telemetry delivery approach described above, -we are still leveraging the VES JSON based model in DCAE. The purpose of -the diagram above is to illustrate the concept only and not to imply a -specific implementation. +For additional information and use cases for the Bulk Telemetry Transmission +Mechanism, please refer to the `5G - Bulk PM ONAP Development `__ +Wiki page. Monitoring & Management Requirements -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ VNF telemetry via standardized interface -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -All VNF telemetry data (e.g. fault event records, syslog records, -performance records, etc.) need to be delivered to ONAP using the -standardized models and interfaces described in this section. +.. req:: + :id: R-821473 + :target: XNF + :keyword: MUST + :introduced: casablanca + :impacts: dcae + :validation_mode: in_service -Encoding and Serialization -~~~~~~~~~~~~~~~~~~~~~~~~~~~ + The xNF MUST produce heartbeat indicators consisting of events containing + the common event header only per the VES Listener Specification. -Content delivered from VNFs to ONAP is to be encoded and serialized using JSON: JSON ~~~~~~~~~~~~~~~~~~ - .. req:: :id: R-19624 :target: XNF :keyword: MUST - The xNF **MUST** encode and serialize content delivered to - ONAP using JSON (RFC 7159) plain text format. High-volume data - is to be encoded and serialized using `Avro `_, - where the Avro [#7.4.1]_ data format are described using JSON. - - Note: - - - JSON plain text format is preferred for moderate volume data sets - (option 1), as JSON has the advantage of having well-understood simple - processing and being human-readable without additional decoding. Examples - of moderate volume data sets include the fault alarms and performance - alerts, heartbeat messages, measurements used for xNF scaling and syslogs. - - Binary format using Avro is preferred for high volume data sets - (option 2) such as mobility flow measurements and other high-volume - streaming events (such as mobility signaling events or SIP signaling) - or bulk data, as this will significantly reduce the volume of data - to be transmitted. As of the date of this document, all events are - reported using plain text JSON and REST. - - Avro content is self-documented, using a JSON schema. The JSON schema is - delivered along with the data content - (http://avro.apache.org/docs/current/ ). This means the presence and - position of data fields can be recognized automatically, as well as the - data format, definition and other attributes. Avro content can be - serialized as JSON tagged text or as binary. In binary format, the - JSON schema is included as a separate data block, so the content is - not tagged, further compressing the volume. For streaming data, Avro - will read the schema when the stream is established and apply the - schema to the received content. + The xNF, when leveraging JSON for events, **MUST** encode and serialize + content delivered to ONAP using JSON (RFC 7159) plain text format. + High-volume data is to be encoded and serialized using + `Avro `_, where the Avro [#7.4.1]_ data + format are described using JSON. + +Note: + + - JSON plain text format is preferred for moderate volume data sets + (option 1), as JSON has the advantage of having well-understood simple + processing and being human-readable without additional decoding. Examples + of moderate volume data sets include the fault alarms and performance + alerts, heartbeat messages, measurements used for xNF scaling and syslogs. + - Binary format using Avro is preferred for high volume data sets + (option 2) such as mobility flow measurements and other high-volume + streaming events (such as mobility signaling events or SIP signaling) + or bulk data, as this will significantly reduce the volume of data + to be transmitted. As of the date of this document, all events are + reported using plain text JSON and REST. + - Avro content is self-documented, using a JSON schema. The JSON schema is + delivered along with the data content + (http://avro.apache.org/docs/current/ ). This means the presence and + position of data fields can be recognized automatically, as well as the + data format, definition and other attributes. Avro content can be + serialized as JSON tagged text or as binary. In binary format, the + JSON schema is included as a separate data block, so the content is + not tagged, further compressing the volume. For streaming data, Avro + will read the schema when the stream is established and apply the + schema to the received content. In addition to the preferred method (JSON), content can be delivered from xNFs to ONAP can be encoded and serialized using Google Protocol Buffers (GPB). -KV-GPB/GPB -~~~~~~~~~~~~~~~~~~ +Google Protocol Buffers (GPB) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. req:: - :id: R-10623 - :target: XNF - :keyword: MUST - :introduced: casablanca + :id: R-257367 + :target: XNF + :keyword: MUST + :introduced: casablanca + :validation_mode: in_service + + The xNF, when leveraging Google Protocol Buffers for events, **MUST** + serialize the events using native Google Protocol Buffers (GPB) where: + + * keys are represented as integers pointing to the system resources for + the xNF being monitored + * values correspond to integers or strings that identify the operational + state of the VNF resource, such a statistics counters and the state of + an xNF resource. + * required Google Protocol Buffers (GPB) metadata is provided in the + form of .proto files. - Telemetry data delivered using Google Protocol Buffers v3 (proto3) - **MUST** be serialized in one of the following methods: - - * Key-value Google Protocol Buffers (KV-GPB) is also known as - self-describing GPB: - - * keys are strings that correspond to the path of the system - resources for the VNF being monitored. - * values correspond to integers or strings that identify the - operational state of the VNF resource, such a statistics counters - and the state of a VNF resource. - * VNF providers must supply valid KV-GPB definition file(s) to allow - for the decoding of all KV-GPB encoded telemetry messages. - - * Native Google Protocol Buffers (GPB) is also known as compact GPB: - - * keys are represented as integers pointing to the system resources for - the VNF being monitored. - * values correspond to integers or strings that identify the operational - state of the VNF resource, such a statistics counters and the state - of a VNF resource. - * Google Protocol Buffers (GPB) requires metadata in the form of .proto - files. VNF providers must supply the necessary GPB .proto files such that - GPB telemetry messages can be encoded and decoded. - -In the future, we may consider support for other types of -encoding & serialization methods based on industry demand. +.. req:: + :id: R-978752 + :target: XNF PROVIDER + :keyword: MUST + :introduced: casablanca + :validation_mode: static + + The xNF providers **MUST** provide to the Service Provider the additional + following artifacts to support the delivery of high-volume xNF telemetry to + DCAE via GPB over TLS/TCP: + + * a valid VES Event .proto definition file, to be used validate and + decode an event + * a valid high volume measurement .proto definition file, to be used for + processing high volume events + * a supporting PM content metadata file to be used by analytics + applications to process high volume measurement events Reporting Frequency ~~~~~~~~~~~~~~~~~~~~~ +.. req:: + :id: R-146931 + :target: XNF + :keyword: MUST + :introduced: casablanca + :validation_mode: in_service + + The xNF **MUST** report exactly one Measurement event per period + per source name. + .. req:: :id: R-98191 :target: XNF @@ -694,7 +857,7 @@ Security regular procedures for securing access and delivery. Bulk Performance Measurement -~~~~~~~~~~ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. req:: :id: R-841740 @@ -718,7 +881,7 @@ Bulk Performance Measurement when supporting the event-driven bulk transfer of monitoring data. .. req:: - :id: R-75943 + :id: R-75943 :target: XNF :keyword: SHOULD :introduced: casablanca @@ -727,22 +890,17 @@ Bulk Performance Measurement The xNF **SHOULD** support the data schema defined in 3GPP TS 32.435, when supporting the event-driven bulk transfer of monitoring data. -.. [#7.4.1] - This option is not currently supported in ONAP and it is currently - under consideration. .. |image0| image:: ../Data_Model_For_Event_Records.png - :width: 7in - :height: 8in .. |image1| image:: ../VES_JSON_Driven_Model.png :width: 5in :height: 3in -.. |image2| image:: ../YANG_Driven_Model.png - :width: 5in - :height: 3in +.. |image2| image:: ../Protocol_Buffers_Driven_Model.png + :width: 4.74in + :height: 3.3in -.. |image3| image:: ../Protocol_Buffers_Driven_Model.png +.. |image3| image:: ../Bulk_Data_Transfer_Mechv1.PNG :width: 4.74in :height: 3.3in diff --git a/docs/data/needs.json b/docs/data/needs.json index 3b97a8c..875fbd2 100644 --- a/docs/data/needs.json +++ b/docs/data/needs.json @@ -1,5 +1,5 @@ { - "created": "2018-09-18T22:51:58.508439", + "created": "2018-09-20T12:49:06.895999", "current_version": "casablanca", "project": "", "versions": { @@ -21858,7 +21858,7 @@ "needs_amount": 750 }, "casablanca": { - "created": "2018-09-18T22:51:58.508358", + "created": "2018-09-20T12:49:06.895999", "needs": { "R-00011": { "description": "A VNF's Heat Orchestration Template's parameter defined\nin a nested YAML file\n**MUST NOT** have a parameter constraint defined.", @@ -24068,6 +24068,34 @@ "validated_by": "", "validation_mode": "" }, + "R-120182": { + "description": "The xNF provider **MUST** indicate specific conditions that may arise, and\nrecommend actions that may be taken at specific thresholds, or if specific\nconditions repeat within a specified time interval, using the semantics and\nsyntax described by the :doc:`VES Event Registration specification<../../../../vnfsdk/module.git/files/VESEventRegistration_3_0>`.", + "full_title": "", + "hide_links": "", + "id": "R-120182", + "impacts": "dcae", + "introduced": "casablanca", + "keyword": "MUST", + "links": [], + "notes": "", + "section_name": "Data Structure Specification of the Event Record", + "sections": [ + "Data Structure Specification of the Event Record", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF PROVIDER", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "static" + }, "R-12110": { "description": "The VNF **MUST NOT** use keys generated or derived from\npredictable functions or values, e.g., values considered predictable\ninclude user identity information, time of day, stored/transmitted data.", "full_title": "", @@ -24126,6 +24154,34 @@ "validated_by": "", "validation_mode": "" }, + "R-123044": { + "description": "The xNF Provider **MAY** require that specific events, identified by their\n``eventName``, require that certain fields, which are optional in the common\nevent format, must be present when they are published.", + "full_title": "", + "hide_links": "", + "id": "R-123044", + "impacts": "dcae", + "introduced": "casablanca", + "keyword": "MUST", + "links": [], + "notes": "", + "section_name": "Data Structure Specification of the Event Record", + "sections": [ + "Data Structure Specification of the Event Record", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF PROVIDER", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "in_service" + }, "R-12467": { "description": "The VNF **MUST NOT** use compromised encryption algorithms.\nFor example, SHA, DSS, MD5, SHA-1 and Skipjack algorithms.\nAcceptable algorithms can be found in the NIST FIPS publications\n(https://csrc.nist.gov/publications/fips) and in the\nNIST Special Publications (https://csrc.nist.gov/publications/sp).", "full_title": "", @@ -24580,6 +24636,35 @@ "validated_by": "", "validation_mode": "" }, + "R-146931": { + "description": "The xNF **MUST** report exactly one Measurement event per period\nper source name.", + "full_title": "", + "hide_links": "", + "id": "R-146931", + "impacts": "", + "introduced": "casablanca", + "keyword": "MUST", + "links": [], + "notes": "", + "section_name": "Reporting Frequency", + "sections": [ + "Reporting Frequency", + "Monitoring & Management Requirements", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "in_service" + }, "R-14853": { "description": "The VNF **MUST** respond to a \"move traffic\" [#4.5.2]_ command\nagainst a specific VNFC, moving all existing session elsewhere with\nminimal disruption if a VNF provides a load balancing function across\nmultiple instances of its VNFCs.\n\nNote: Individual VNF performance aspects (e.g., move duration or\ndisruption scope) may require further constraints.", "full_title": "", @@ -25463,7 +25548,7 @@ "validation_mode": "" }, "R-19624": { - "description": "The xNF **MUST** encode and serialize content delivered to\nONAP using JSON (RFC 7159) plain text format. High-volume data\nis to be encoded and serialized using `Avro `_,\nwhere the Avro [#7.4.1]_ data format are described using JSON.\n\nNote:\n\n - JSON plain text format is preferred for moderate volume data sets\n (option 1), as JSON has the advantage of having well-understood simple\n processing and being human-readable without additional decoding. Examples\n of moderate volume data sets include the fault alarms and performance\n alerts, heartbeat messages, measurements used for xNF scaling and syslogs.\n - Binary format using Avro is preferred for high volume data sets\n (option 2) such as mobility flow measurements and other high-volume\n streaming events (such as mobility signaling events or SIP signaling)\n or bulk data, as this will significantly reduce the volume of data\n to be transmitted. As of the date of this document, all events are\n reported using plain text JSON and REST.\n - Avro content is self-documented, using a JSON schema. The JSON schema is\n delivered along with the data content\n (http://avro.apache.org/docs/current/ ). This means the presence and\n position of data fields can be recognized automatically, as well as the\n data format, definition and other attributes. Avro content can be\n serialized as JSON tagged text or as binary. In binary format, the\n JSON schema is included as a separate data block, so the content is\n not tagged, further compressing the volume. For streaming data, Avro\n will read the schema when the stream is established and apply the\n schema to the received content.", + "description": "The xNF, when leveraging JSON for events, **MUST** encode and serialize\ncontent delivered to ONAP using JSON (RFC 7159) plain text format.\nHigh-volume data is to be encoded and serialized using\n`Avro `_, where the Avro [#7.4.1]_ data\nformat are described using JSON.", "full_title": "", "hide_links": "", "id": "R-19624", @@ -26993,6 +27078,35 @@ "validated_by": "", "validation_mode": "static" }, + "R-257367": { + "description": "The xNF, when leveraging Google Protocol Buffers for events, **MUST**\nserialize the events using native Google Protocol Buffers (GPB) where:\n\n * keys are represented as integers pointing to the system resources for\n the xNF being monitored\n * values correspond to integers or strings that identify the operational\n state of the VNF resource, such a statistics counters and the state of\n an xNF resource.\n * required Google Protocol Buffers (GPB) metadata is provided in the\n form of .proto files.", + "full_title": "", + "hide_links": "", + "id": "R-257367", + "impacts": "", + "introduced": "casablanca", + "keyword": "MUST", + "links": [], + "notes": "", + "section_name": "Google Protocol Buffers (GPB)", + "sections": [ + "Google Protocol Buffers (GPB)", + "Monitoring & Management Requirements", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "in_service" + }, "R-25877": { "description": "A VNF's Heat Orchestration Template's parameter name\n(i.e., ) **MUST** contain only alphanumeric\ncharacters and underscores ('_').", "full_title": "", @@ -27567,6 +27681,35 @@ "validated_by": "", "validation_mode": "static" }, + "R-283988": { + "description": "The VNF, when publishing events, **MUST NOT** send information through\nextensible structures if the event specification has explicitly defined\nfields for that information.", + "full_title": "", + "hide_links": "", + "id": "R-283988", + "impacts": "dcae", + "introduced": "casablanca", + "keyword": "MUST NOT", + "links": [], + "notes": "", + "section_name": "Miscellaneous", + "sections": [ + "Miscellaneous", + "Event Records - Data Structure Description", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "VNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "in_service" + }, "R-28545": { "description": "The xNF **MUST** conform its YANG model to RFC 6060,\n\"YANG - A Data Modeling Language for the Network Configuration\nProtocol (NETCONF)\".", "full_title": "", @@ -30071,6 +30214,35 @@ "validated_by": "", "validation_mode": "" }, + "R-408813": { + "description": "The VNF, when publishing events, **MUST** pass all information it is\nable to collect even if the information field is identified as optional.\nHowever, if the data cannot be collected, then optional fields can be\nomitted.", + "full_title": "", + "hide_links": "", + "id": "R-408813", + "impacts": "dcae", + "introduced": "casablanca", + "keyword": "MUST", + "links": [], + "notes": "", + "section_name": "Miscellaneous", + "sections": [ + "Miscellaneous", + "Event Records - Data Structure Description", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "VNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "none" + }, "R-40899": { "description": "When the VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``\nproperty ``name`` parameter is defined as a ``string``, a parameter\n**MUST** be delcared for\neach ``OS::Nova::Server`` resource associated with the ``{vm-type}``.", "full_title": "", @@ -31641,6 +31813,35 @@ "validated_by": "", "validation_mode": "" }, + "R-470963": { + "description": "The VNF, when publishing events, **MUST** leverage camel case to separate\nwords and acronyms used as keys that will be sent through extensible fields.\nWhen an acronym is used as the key, then only the first letter shall be\ncapitalized.", + "full_title": "", + "hide_links": "", + "id": "R-470963", + "impacts": "dcae", + "introduced": "casablanca", + "keyword": "MUST", + "links": [], + "notes": "", + "section_name": "Miscellaneous", + "sections": [ + "Miscellaneous", + "Event Records - Data Structure Description", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "VNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "in_service" + }, "R-47204": { "description": "The VNF **MUST** be capable of protecting the confidentiality and integrity\nof data at rest and in transit from unauthorized access and modification.", "full_title": "", @@ -32530,6 +32731,34 @@ "validated_by": "", "validation_mode": "" }, + "R-520802": { + "description": "The xNF provider **MUST** provide a YAML file formatted in adherence with\nthe :doc:`VES Event Registration specification<../../../../vnfsdk/module.git/files/VESEventRegistration_3_0>`\nthat defines the following information for each event produced by the VNF:\n\n* ``eventName``\n* Required fields\n* Optional fields\n* Any special handling to be performed for that event", + "full_title": "", + "hide_links": "", + "id": "R-520802", + "impacts": "dcae", + "introduced": "casablanca", + "keyword": "MUST", + "links": [], + "notes": "", + "section_name": "Data Structure Specification of the Event Record", + "sections": [ + "Data Structure Specification of the Event Record", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF PROVIDER", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "static" + }, "R-52425": { "description": "A VNF's port connected to an internal network **MUST**\nuse the port for the purpose of reaching VMs in the same VNF.", "full_title": "", @@ -32672,6 +32901,35 @@ "validated_by": "", "validation_mode": "" }, + "R-528866": { + "description": "The VNF **MUST** produce VES events that include the following mandatory\nfields in the common event header\n\n * ``domain`` - the event domain enumeration\n * ``eventId`` - the event key unique to the event source\n * ``eventName`` - the unique event name\n * ``lastEpochMicrosec`` - the latest unix time (aka epoch time) associated\n with the event\n * ``priority`` - the processing priority enumeration\n * ``reportingEntityName`` - name of the entity reporting the event or\n detecting a problem in another xNF\n * ``sequence`` - the ordering of events communicated by an event source\n * ``sourceName`` - name of the entity experiencing the event issue, which\n may be detected and reported by a separate reporting entity\n * ``startEpochMicrosec`` - the earliest unix time (aka epoch time)\n associated with the event\n * ``version`` - the version of the event header\n * ``vesEventListenerVersion`` - Version of the VES event listener API spec\n that this event is compliant with", + "full_title": "", + "hide_links": "", + "id": "R-528866", + "impacts": "dcae", + "introduced": "casablanca", + "keyword": "MUST", + "links": [], + "notes": "", + "section_name": "Common Event Header", + "sections": [ + "Common Event Header", + "Event Records - Data Structure Description", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "VNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "in_service" + }, "R-53015": { "description": "The xNF **MUST** apply locking based on the sequence of\nNETCONF operations, with the first configuration operation locking\nout all others until completed.", "full_title": "", @@ -33553,6 +33811,34 @@ "validated_by": "", "validation_mode": "" }, + "R-570134": { + "description": "The events produced by the xNF **MUST** must be compliant with the common\nevent format defined in the\n:doc:`VES Event Listener<../../../../vnfsdk/model.git/docs/files/VESEventListener_7_0_1>`\nspecification.", + "full_title": "", + "hide_links": "", + "id": "R-570134", + "impacts": "dcae", + "introduced": "casablanca", + "keyword": "MUST", + "links": [], + "notes": "", + "section_name": "Data Structure Specification of the Event Record", + "sections": [ + "Data Structure Specification of the Event Record", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "in_service" + }, "R-57282": { "description": "Each VNF's Heat Orchestration Template's ``{vm-type}`` **MUST**\nhave a unique parameter name for the ``OS::Nova::Server`` property\n``image`` even if more than one ``{vm-type}`` shares the same image.", "full_title": "", @@ -35034,6 +35320,35 @@ "validated_by": "", "validation_mode": "" }, + "R-659655": { + "description": "The xNF **SHOULD** leverage the JSON-driven model, as depicted in Figure 2,\nfor data delivery unless there are specific performance or operational\nconcerns agreed upon by the Service Provider that would warrant using an\nalternate model.", + "full_title": "", + "hide_links": "", + "id": "R-659655", + "impacts": "dcae", + "introduced": "casablanca", + "keyword": "SHOULD", + "links": [], + "notes": "", + "section_name": "xNF Telemetry using VES/JSON Model", + "sections": [ + "xNF Telemetry using VES/JSON Model", + "Transports and Protocols Supporting Resource Interfaces", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "in_service" + }, "R-66070": { "description": "The xNF Package **MUST** include xNF Identification Data to\nuniquely identify the resource for a given xNF provider. The identification\ndata must include: an identifier for the xNF, the name of the xNF as was\ngiven by the xNF provider, xNF description, xNF provider, and version.", "full_title": "", @@ -35772,6 +36087,35 @@ "validated_by": "", "validation_mode": "" }, + "R-697654": { + "description": "The xNF **MAY** leverage the Google Protocol Buffers (GPB) delivery model\ndepicted in Figure 3 to support real-time performance management (PM) data.\nIn this model the VES events are streamed as binary-encoded GBPs over via\nTCP sockets", + "full_title": "", + "hide_links": "", + "id": "R-697654", + "impacts": "dcae", + "introduced": "casablanca", + "keyword": "MAY", + "links": [], + "notes": "", + "section_name": "xNF Telemetry using Google Protocol Buffers", + "sections": [ + "xNF Telemetry using Google Protocol Buffers", + "Transports and Protocols Supporting Resource Interfaces", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "in_service" + }, "R-69874": { "description": "A VNF's ``{network-role}`` assigned to an internal network **MUST**\nbe different than the ``{network-role}`` assigned to the VNF's external\nnetworks.", "full_title": "", @@ -37511,6 +37855,34 @@ "validated_by": "", "validation_mode": "" }, + "R-798933": { + "description": "The xNF **SHOULD** deliver event records that fall into the event domains\nsupported by VES.", + "full_title": "", + "hide_links": "", + "id": "R-798933", + "impacts": "dcae", + "introduced": "casblanca", + "keyword": "SHOULD", + "links": [], + "notes": "", + "section_name": "Transports and Protocols Supporting Resource Interfaces", + "sections": [ + "Transports and Protocols Supporting Resource Interfaces", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "in_service" + }, "R-79952": { "description": "The VNF **SHOULD** support container snapshots if not for rebuild\nand evacuate for rollback or back out mechanism.", "full_title": "", @@ -37938,6 +38310,63 @@ "validated_by": "", "validation_mode": "static" }, + "R-821473": { + "description": "The xNF MUST produce heartbeat indicators consisting of events containing\nthe common event header only per the VES Listener Specification.", + "full_title": "", + "hide_links": "", + "id": "R-821473", + "impacts": "dcae", + "introduced": "casablanca", + "keyword": "MUST", + "links": [], + "notes": "", + "section_name": "VNF telemetry via standardized interface", + "sections": [ + "VNF telemetry via standardized interface", + "Monitoring & Management Requirements", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "in_service" + }, + "R-821839": { + "description": "The xNF **MUST** deliver event records to ONAP using the common transport\nmechanisms and protocols defined in this document.", + "full_title": "", + "hide_links": "", + "id": "R-821839", + "impacts": "dcae", + "introduced": "casblanca", + "keyword": "MUST", + "links": [], + "notes": "", + "section_name": "Transports and Protocols Supporting Resource Interfaces", + "sections": [ + "Transports and Protocols Supporting Resource Interfaces", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "in_service" + }, "R-82223": { "description": "The VNF **MUST** be decomposed if the functions have\nsignificantly different scaling characteristics (e.g., signaling\nversus media functions, control versus data plane functions).", "full_title": "", @@ -40148,6 +40577,35 @@ "validated_by": "", "validation_mode": "" }, + "R-908291": { + "description": "The XNF **MAY** leverage bulk xNF telemetry transmission mechanism, as\ndepicted in Figure 4, in instances where other transmission methods are not\npractical or advisable.", + "full_title": "", + "hide_links": "", + "id": "R-908291", + "impacts": "dcae, dmaap", + "introduced": "casablanca", + "keyword": "MAY", + "links": [], + "notes": "", + "section_name": "Bulk Telemetry Transmission", + "sections": [ + "Bulk Telemetry Transmission", + "Transports and Protocols Supporting Resource Interfaces", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "in_service" + }, "R-91125": { "description": "The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``\nproperty\n``image`` parameter **MUST** be enumerated in the Heat Orchestration\nTemplate's Environment File and a value **MUST** be assigned.", "full_title": "", @@ -40547,6 +41005,34 @@ "validated_by": "", "validation_mode": "static" }, + "R-932071": { + "description": "The xNF provider **MUST** reach agreement with the Service Provider on\nthe selected methods for encoding, serialization and data delivery\nprior to the on-boarding of the xNF into ONAP SDC Design Studio.", + "full_title": "", + "hide_links": "", + "id": "R-932071", + "impacts": "dcae", + "introduced": "casblanca", + "keyword": "MUST", + "links": [], + "notes": "", + "section_name": "Transports and Protocols Supporting Resource Interfaces", + "sections": [ + "Transports and Protocols Supporting Resource Interfaces", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "none" + }, "R-93272": { "description": "A VNF **MAY** have one or more ports connected to a unique\nexternal network. All VNF ports connected to the unique external\nnetwork **MUST** have Cloud Assigned IP Addresses\nor **MUST** have ONAP SDN-C assigned IP addresses.", "full_title": "", @@ -41319,6 +41805,35 @@ "validated_by": "", "validation_mode": "static" }, + "R-978752": { + "description": " The xNF providers **MUST** provide to the Service Provider the additional\n following artifacts to support the delivery of high-volume xNF telemetry to\n DCAE via GPB over TLS/TCP:\n\n * a valid VES Event .proto definition file, to be used validate and\n decode an event\n * a valid high volume measurement .proto definition file, to be used for\n processing high volume events\n * a supporting PM content metadata file to be used by analytics\n applications to process high volume measurement events", + "full_title": "", + "hide_links": "", + "id": "R-978752", + "impacts": "", + "introduced": "casablanca", + "keyword": "MUST", + "links": [], + "notes": "", + "section_name": "Google Protocol Buffers (GPB)", + "sections": [ + "Google Protocol Buffers (GPB)", + "Monitoring & Management Requirements", + "Monitoring & Management" + ], + "status": null, + "tags": [], + "target": "XNF PROVIDER", + "test": "", + "test_case": "", + "test_file": "", + "title": "", + "title_from_content": "", + "type_name": "Requirement", + "updated": "", + "validated_by": "", + "validation_mode": "static" + }, "R-98138": { "description": "When a VNF's Heat Orchestration Template's resource is associated with a\nsingle internal network, the Resource ID **MUST** contain the text\n``int_{network-role}``.", "full_title": "", @@ -41937,7 +42452,7 @@ "validation_mode": "static" } }, - "needs_amount": 705 + "needs_amount": 723 } } } \ No newline at end of file -- 2.16.6