Open APIs

Expand all | Collapse all

Proposal for NIX Protocol

  • 1.  Proposal for NIX Protocol

    TM Forum Member
    Posted Jan 16, 2019 11:47

    Hi All,

    Following is a proposal on the NIX Protocol - Network Information Exchange Protocol. If the Open API community concur for the need, will step into the further process of documentation and API development. Please guide and let me know your feedback.

    INTRODUCTION

    The following document is the proposal for standardizing the maintenance activity related email communication between network companies. Globally network companies do partner with other network carriers for capacity augmentation and riding services to the customers. During maintenance activities that could impact the circuits of partnered companies, the communication happens in nonstandard email format. Though automation and standardization are experimented by some carriers since no standardization is in place, adopting communication means as per one's practice would be very much challenging without standardization. Hence there is a lot of manual process in place to covert the nonstandard email format communication into digital records.

    While standardizing identified following key important attributes in maintenance activity that could impact partner companies' associated circuits or NEs or customers.

    • Reference ID à Unique reference ID to communicate with network carrier partner for further communication regarding the maintenance activity(s)
    • Network Carrier name à Sending company name who is going to perform the maintenance activity(s) that could impact the email recipient network company
    • Subject à A one-line brief summary of maintenance activity(s) going to be performed
    • Start Date and time along with time zones (local and GMT) à A set of start dates with associated time and zones information (In case of multiple maintenance activities planned in various windows of different dates or only one date time and zone). Time zone should be mentioned in the local time zone (EST/PST/CST) where the maintenance activity is going to be performed along with GMT +/- hours. Format MM/DD/YYYY HH24:MI:SS.sss XST/GMT-5
    • End Date and time along with time zones (local and GMT) à A set of corresponding end dates, time and zone for each start date. Format MM/DD/YYYY HH24:MI:SS.sss XST/GMT-5
    • Outage window Duration à If Multiple start/end dates are given either single outage window for all maintenance activities included can be provided or provide a set that corresponds to an individual pair of start/end dates. Format HH:MI:SS.sss
    • Impact Duration à Actual impact duration for every corresponding start/end date. Format HH:MI:SS.sss
    • NE Type à On what type of network element the maintenance activity is going to be performed on. Ex: - Switch/Circuit/Router
    • NE Details à List of impacted NEs. If there is a relation between the date window and NEs list, then have a set of sets corresponding to each start/end dates.
    • Detailed work description à A full work description of the maintenance activity. Free flow text.
    • Update Flag à Is this notification an update notification of the previous email? 0 à Not an update, 1à Postpone notification, 2à Prepone notification
    • Emergency à Yes or No, generally for the notifications below 24 hrs lead time this flag will be enabled
    • Severity à High/Medium/Low depends on multiple factors duration, number of circuits, impacted customer base
    • URL info à Any extranet URL to login and see the maintenance activity details else N/A
    • Location à Where is the maintenance activity happening? Could be different locations based on the NE presence.
    • Maps info à A set of Maps location URLs or lat-long coordinates or N/A
    • Contact info à Contact email and phone number about the maintenance activity

    Sample Json with Maintenance Activities

     

    {

      "RefID": {},

      "CarrierName": {},

      "Subject": {},

      "Actvities": {

        "Activity1": {

          "ActivityID": {},

          "StartDateTimeZone": {},

          "EndDateTimeZone": {},

          "OutageWindow": {},

          "ImpactDuration": {},

          "NEType": {},

          "NEDetails": {},

          "WorkDescription": {},

          "Location": {},

          "Severity": {}

        },

        "Activity2": {

          "ActivityID": {},

          "StartDateTimeZone": {},

          "EndDateTimeZone": {},

          "OutageWindow": {},

          "ImpactDuration": {},

          "NEType": {},

          "NEDetails": {},

          "WorkDescription": {},

          "Location": {},

          "Severity": {}

        }

      },

      "UpdateFlag": {},

      "Emergency": {},

      "URL": {},

      "MAPsInfo": {},

      "ContactEmail": {},

      "ContactPhone": {},

      "ContactAddress": {}

    }

     



    ------------------------------
    Adithya Umakanth
    Verizon Communications
    ------------------------------


  • 2.  RE: Proposal for NIX Protocol

    TM Forum Member
    Posted Jan 17, 2019 07:38
    Does this differ from the trouble ticket model developed in ATIS TR 217 ( noting this is JSON Based )?

    ------------------------------

    Dave Milham TM Forum Chief Architect, TM Forum
    ------------------------------



  • 3.  RE: Proposal for NIX Protocol

    TM Forum Member
    Posted Jan 17, 2019 08:41
    Hi Dave,

    Thanks for the response,

    Yes, it is different from trouble ticket model.

    Trouble ticket model talks about the ticket tracking within the organization.

    NIX is about maintenance activity notification across organizations.

    One Telecom/Network organization may serve N other organizations since there is no standardization in place, organizations are notifying about maintenance activities that could impact partnered networks over emails.

    I referred following two articles as per your suggestion, Please guide me if I missed reading the right articles.

    https://projects.tmforum.org/wiki/pages/viewpage.action?spaceKey=PUB&title=TMF621+Trouble+Ticket+API+REST+Specification+R18.0.1
    https://www.tmforum.org/resources/standard/tr217-partnership-revenue-models-v0-5-2/


    Thank You
    Adithya

    ------------------------------
    Adithya Umakanth
    Verizon Communications
    ------------------------------



  • 4.  RE: Proposal for NIX Protocol

    TM Forum Member
    Posted Jan 17, 2019 09:24
    Thanks for prompt response
    Apologies got the number wrong ( typo)
    Should have been T1.227 from ATIS equivalent  ITU   X790 Trouble ticketing ( not sure if ATIS has retired this standard.)
    These do  address scheduled maintenance as well as trouble ticket between organisation. I was curious as to whether  NIX requirements and the schedule maintenance in this proposal were related.

    ------------------------------
    Dave Milham
    TM Forum Chief Architect, TM Forum
    ------------------------------



  • 5.  RE: Proposal for NIX Protocol

    TM Forum Member
    Posted Jan 17, 2019 08:41
    Hi Adithya

    Do you think the diversity inclusion will let the customer know that there is a diversity pathing avbl to continue the service without any disruption.

    ------------------------------
    steve johnson
    Verizon Communications
    ------------------------------



  • 6.  RE: Proposal for NIX Protocol

    TM Forum Member
    Posted Jan 17, 2019 09:45
    Hi John

    Yes, we should consider if the diversity path is available that will not impact the service, worth mentioning as part of the JSON object.
    Will enhance the object with your input.

    Thanks a lot for your suggestion

    Thank You
    Adithya

    ------------------------------
    Adithya Umakanth
    Verizon Communications
    ------------------------------



  • 7.  RE: Proposal for NIX Protocol

    TM Forum Member
    Posted Jan 21, 2019 02:08
    Edited by Sergey Zak Jan 21, 2019 18:01
    Adithya, that's a good undertaking.
    However I foresee difficulties figuring impact on all parties involved, as there seems to be a need to be able to correctly transcribe network service topology, across multiple parties / providers. They typically have their own databases of reference, often with incompatible format. Often having just NE name is not good, because there may be 12 shelves with 12 cards in each, and maybe 12 ports in each card. Assuming all that at risk could be blocking quite a lot. A common language to unambiguously describe infrastructure elements, services provided by network, and their relations can be tricky. From your description, ​it would be down to each responsible person to identify the actual risk based on his/her understanding of the textual description of work planned, name of the element, and probably navigation in their own data records to figure out what's at risk. E.g. the process is mostly manual - but that could just be fine with what you trying to accomplish.

    ------------------------------
    Sergey Zak
    Australia
    Senior Domain Architect
    ------------------------------



  • 8.  RE: Proposal for NIX Protocol

    TM Forum Member
    Posted Jan 22, 2019 05:47
    We have  looked at the requirements for  interconnecting connectivity domains
    initial study was in ZOOM/ODA  TR275 Core Networking Resources Business Entities R18.5.0
    However we concluded in ODA GB999 User Guide for Network Slice Management R18.5.0  that for 5G ( and other connectivity services) we needed a simplified Service view of Connectivity Domains and their interconnection; so we put together the candidates entities required and the ODA Production team is now working with the SID and API teams on SID enhancement and API  Data models for connectivity Service
    this leverages thinking in API and SID program and prior ZOOM /ODA work in  TR255 Resource Function Activation and Configuration Suite R17.5.0  especially Parts A and B . This proposed a service view of the resource topologies which means operators don't have to reveal all the low level resource topology as part of the Connectivity Service which means the service topology is much simply and does not change when underlying resources change as happens with virtualised solution.  It also addresses network security needs

    ------------------------------
    Dave Milham
    TM Forum Chief Architect, TM Forum
    ------------------------------



  • 9.  RE: Proposal for NIX Protocol

    TM Forum Member
    Posted Jan 21, 2019 04:38
    WRT  Network Carrier name

    Carrier codes are issued and maintained by the ITU
    See https://www.itu.int/oth/T0201

    Data network Identifier DNIC in ITU Operational bulletins see https://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-OB.714-2000-PDF-E.pdf

    Int'l Leased circuit identifier structure is ITU  M.1400  series  see
    https://www.itu.int/rec/T-REC-M.1400/en

    Which is why I asked the question about X.790 which includes scheduled maintenance and was originally developed for int'l leased circuits.

    ------------------------------
    Dave Milham
    TM Forum Chief Architect, TM Forum
    ------------------------------



  • 10.  RE: Proposal for NIX Protocol

    TM Forum Member
    Posted Jan 25, 2019 06:28
    Hi All,

    Thanks a lot for the inputs,

    Here are my thoughts on NIX Proposal

    1) I am not proposing standardization in Circuit naming convention.
    2) Verizon partners with 250 other network organizations globally (Both in the domestic US and internationally)
    3) We receive maintenance notification emails in non-standard format by the carrier. (Attached 5 sample emails from different carriers globally)
    4) NIX is a proposal to standardize the email format only, create Open API to generate and read such standardized emails.
    5) Without standardization, these network/telecom organizations are relying on manual/rules/tools to process these emails and feed into internal systems.

    Please let me know how to proceed.

    ------------------------------
    Adithya Umakanth
    Verizon Communications
    ------------------------------

    Attachment(s)

    htm
    Airtel1.htm   99K 1 version
    html
    Cent1.html   18K 1 version
    html
    Orange.html   27K 1 version
    html
    wind.html   5K 1 version