[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                          Yunbin Xu
Internet Draft                                                      CATR
Intended status: Informational
Expires: January2016
                                                            Guoying Zhang
                                                                     CATR
                                                             July 6, 2015


        Requirements of Abstract Alarm Report in ACTN architecture
              draft-xu-teas-actn-abstract-alarm-report-00.txt


Status of this Memo
   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on January 6, 2016.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info)in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in



<Xu>                    Expires January 6,2016                  [Page 1]


Internet-Draft      actn-abstract-alarm-report                 July 2015
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.

Abstract

   This draft provides a set of requirements for alarm abstraction and
   report of transport networks in the ACTN architecture.

Table of Contents

   1. Introduction...................................................3
   2. Requirements for Alarm Report in ACTN Architecture.............3
   3. Abstract for alarm report in ACTN architecture.................5
      3.1. Status changes report inner abstract node.................5
      3.1. Status changes report inner abstract link.................5
      3.2. Alarm report for abstract node and link...................5
      3.3. Abstract alarm report for connection......................6
   4. Security Considerations........................................6
   5. IANA Considerations............................................6
   6. References.....................................................6
      6.1. Informative References....................................6




<Xu>                    Expires January 6,2016                 [Page 2]


Internet-Draft      actn-abstract-alarm-report                July 2015
1. Introduction

   This draft provides a set of requirements for alarm abstraction and
   report in ACTN architecture. [ACTN-frame] defines the base reference
   architecture and terminology.

   Section 2 provides the requirements for alarm report in ACTN
   architecture. Section 3 provides some solutions for alarm
   abstraction of transport networks.

2. Requirements for Alarm Report in ACTN Architecture

   In ACTN architecture, Physical Network controller (PNC) can access
   to all of the network resources and alarm information, and provides
   an abstracted view of transport network resources to upper layer
   controller based on different abstraction policy. Multi-Domain
   Service Controller (MDSC) gets the abstracted network resource
   information, and shields the networks resources details to Customer
   Network Controller (CNC).

   How to report alarm between PNC and MDSC or between MDSC and CNC is
   related to the abstraction policy. In figure 1, several different
   abstraction particles are listed as follow.

   1) The NE1, NE2 and NE3 in PNC1 is abstracted as NE1', the NE4, NE5
      and NE6 in PNC1 is abstracted as NE2' in MDSC.

   2) The NE7 and NE8 managed by PNC2 is abstracted as NE3' in MDSC.

   3) The multiple links between NE2 and NE4, which is abstracted as a
      link between NE1' and NE2', uses a link bundling mechanism, and
      the bandwidth of this link in MDSC is bound to the sum of
      bandwidth of bundling link in PNC1.

   4) MDSC can shield the network resources details, and only provides
      the information of the edge node and the connection relationship
      between these nodes.




<Xu>                    Expires January 6,2016                    [Page 3]


Internet-Draft        actn-abstract-alarm-report                July 2015
     +-------------------------------------------------------+
     |   +-----+                                     +-----+ |
     |   |NE1''|-------------------------------------|NE2''| |
     |   +-----+                                     +-----+ |
     |CNC  /|\                                         /|\   |
     +------|-------------------------------------------|----+
            |                                           |
     +------|-------------------------------------------|----+
     |   +----+                +----+                +----+  |
     |   |NE1'|----------------|NE2'|----------------|NE3'|  |
     |   |    |---------X------|    |                |    |  |
     |   +----+                +----+                +----+  |
     |MDSC /|\                   /|\                   /|\   |
     +------|---------------------|---------------------|----+
            |                     |                     |
   +------------------------------------------+         |
   | +-----------------+ +--------------+ PNC1|         |
   | | +---+     +---+ | | +---+        |     |         |
   | | |NE1|--X--|NE2|=====|NE4|----+   |     |         |
   | | +---+     +---+ | | +---+    |   |     | +---------------+
   | |   |         /   | |          |   |     | |          PNC2 |
   | |   |     +---+   | | +---+  +---+ |     | | +---+   +---+ |
   | |   +-----|NE3|---X---|NE5|--|NE6|-----------|NE7|---|NE8| |
   | |         +---+   | | +---+  +---+ |     | | +---+   +---+ |
   | +-----------------+ +--------------+     | |               |
   +------------------------------------------+ +---------------+

                Figure 1 Error Report in ACTN architecture

   Based on the different abstract methods, when the underlying network
   resource error occurs, the requirements of alarm reporting mechanism
   is also different.

   1) PNC is able to collect all of the underlying network resource and
      alarm information.

   2) When an error occurs in the link between the NE1 and NE2 in PNC1,
      it shouldn't report an alarm to MDSC, but report the network
      resource status has changed inner the NE1', such as the
      connectivity between the port of NE1', or the maximum available
      bandwidth has changed, etc..

   3) When one of a link between the NE2 and NE4 failures, PNC1 should
      report the bundling link bandwidth changes to MDSC.



<Xu>                    Expires January 6,2016                  [Page 4]


Internet-Draft      actn-abstract-alarm-report                 July 2015
   4) When the link between NE3 and NE5 failures, it is abstracted as a
      link in MDSC, and the PNC1 should report the alarm information,
      indicating that the link is faulty.

   5) In addition, when the underlying network resources failure, due
      to the abstract policy, PNC reporting the resource status changes
      to MDSC, such as abstract node internal state changes and
      abstract link bandwidth property changes, when the upper
      controller MDSC or CNC received these state changes, it cannot
      correlation the state changes to the network connections which
      are impacted. Therefore, the underlying controller PNC or MDSC
      should report the impact of the LSP and alarm information, the
      upper layer controller based on these information and correlated
      with the connection it stored.


3. Abstract for alarm report in ACTN architecture

       3.1. Status changes report inner abstract node

   TBD

       3.2. Status changes report inner abstract link

   When an error occurs in a bundling link, the following information
   should be reported.

   - Domain ID;

   - Bundling link ID;

   - Available Bandwidth;

   - Reason for status change;

   - Occurrence time.

       3.3. Alarm report for abstract node and link

   When an error occurs out of a bundling link or for an abstract node,
   follow alarm information should be reported.

   - Domain ID;

   - Abstract node ID or abstract link ID

   - Alarm reason;



<Xu>                      Expires January 6,2016               [Page 5]


Internet-Draft        actn-abstract-alarm-report              July 2015
   - Alarm level;

   - Occurrence time.



       3.4. Abstract alarm report for connection

   When an error occurs and it impacts a network connection, the follow
   alarm information should be reported.

   - Domain ID;

   - Abstract network connection ID;

   - Alarm reason;
   - Alarm level;

   - Occurrence time.



4. Security Considerations

   This document raises no new security issues.

5. IANA Considerations

   No new IANA considerations are raised by this document.

6. References

6.1. Informative References

   [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and
             Control of Transport Networks", draft-ceccarelli-actn-
             framework, work in progress.




<Xu>                      Expires January 6,2016               [Page 6]


Internet-Draft      actn-abstract-alarm-report             July 2015
Authors' Address

   Yunbin Xu
   China Academy of Telecom Research
   NO.52 Huayuan Beilu, Haidian District, Beijing, China
   Email: xuyunbin@catr.cn

   Guoying Zhang
   China Academy of Telecom Research
   NO.52 Huayuan Beilu, Haidian District, Beijing, China
   Email: zhangguoying@catr.cn




<Xu>                    Expires January 6,2016             [Page 7]