Mapping and Interworking of Diversion Information between Diversion and History-Info Header Fields in the Session Initiation Protocol (SIP)
draft-mohali-rfc6044bis-02
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7544.
|
|
|---|---|---|---|
| Author | Marianne Mohali | ||
| Last updated | 2020-01-21 (Latest revision 2015-03-04) | ||
| RFC stream | Independent Submission | ||
| Intended RFC status | Informational | ||
| Formats | |||
| IETF conflict review | conflict-review-mohali-rfc6044bis | ||
| Stream | ISE state | Published RFC | |
| Consensus boilerplate | Unknown | ||
| Document shepherd | Eliot Lear | ||
| Shepherd write-up | Show Last changed 2015-03-09 | ||
| IESG | IESG state | Became RFC 7544 (Informational) | |
| Telechat date | (None) | ||
| Responsible AD | Ben Campbell | ||
| Send notices to | (None) | ||
| IANA | IANA review state | IANA OK - No Actions Needed | |
| IANA action state | No IANA Actions |
draft-mohali-rfc6044bis-02
Network Working Group S. Vallin
Internet-Draft Stefan Vallin AB
Intended status: Standards Track M. Bjorklund
Expires: May 26, 2019 Cisco
November 22, 2018
YANG Alarm Module
draft-ietf-ccamp-alarm-module-06
Abstract
This document defines a YANG module for alarm management. It
includes functions for alarm list management, alarm shelving and
notifications to inform management systems. There are also
operations to manage the operator state of an alarm and
administrative alarm procedures. The module carefully maps to
relevant alarm standards.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 26, 2019.
Copyright Notice
Copyright (c) 2018 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 Section 4.e of
Vallin & Bjorklund Expires May 26, 2019 [Page 1]
Internet-Draft YANG Alarm Module November 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Notation . . . . . . . . . . . . . . . . 3
2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Alarm Module Concepts . . . . . . . . . . . . . . . . . . . . 5
3.1. Alarm Definition . . . . . . . . . . . . . . . . . . . . 5
3.2. Alarm Type . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Identifying the Alarming Resource . . . . . . . . . . . . 7
3.4. Identifying Alarm Instances . . . . . . . . . . . . . . . 8
3.5. Alarm Life-Cycle . . . . . . . . . . . . . . . . . . . . 8
3.5.1. Resource Alarm Life-Cycle . . . . . . . . . . . . . . 9
3.5.2. Operator Alarm Life-cycle . . . . . . . . . . . . . . 10
3.5.3. Administrative Alarm Life-Cycle . . . . . . . . . . . 10
3.6. Root Cause, Impacted Resources and Related Alarms . . . . 10
3.7. Alarm Shelving . . . . . . . . . . . . . . . . . . . . . 11
3.8. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 12
4. Alarm Data Model . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Alarm Control . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1. Alarm Shelving . . . . . . . . . . . . . . . . . . . 14
4.2. Alarm Inventory . . . . . . . . . . . . . . . . . . . . . 14
4.3. Alarm Summary . . . . . . . . . . . . . . . . . . . . . . 15
4.4. The Alarm List . . . . . . . . . . . . . . . . . . . . . 16
4.5. The Shelved Alarms List . . . . . . . . . . . . . . . . . 18
4.6. Alarm Profiles . . . . . . . . . . . . . . . . . . . . . 18
4.7. Operations . . . . . . . . . . . . . . . . . . . . . . . 19
4.8. Notifications . . . . . . . . . . . . . . . . . . . . . . 19
5. Relationship to the ietf-hardware YANG module . . . . . . . . 19
6. Alarm YANG Module . . . . . . . . . . . . . . . . . . . . . . 20
7. X.733 Extensions . . . . . . . . . . . . . . . . . . . . . . 50
8. The X.733 Mapping Module . . . . . . . . . . . . . . . . . . 51
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
10. Security Considerations . . . . . . . . . . . . . . . . . . . 63
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 64
12.1. Normative References . . . . . . . . . . . . . . . . . . 64
12.2. Informative References . . . . . . . . . . . . . . . . . 65
Appendix A. Vendor-specific Alarm-Types Example . . . . . . . . 66
Appendix B. Alarm Inventory Example . . . . . . . . . . . . . . 67
Appendix C. Alarm List Example . . . . . . . . . . . . . . . . . 68
Appendix D. Alarm Shelving Example . . . . . . . . . . . . . . . 69
Appendix E. X.733 Mapping Example . . . . . . . . . . . . . . . 70
Appendix F. Relationship to other alarm standards . . . . . . . 71
F.1. Alarm definition . . . . . . . . . . . . . . . . . . . . 71
F.2. Data model . . . . . . . . . . . . . . . . . . . . . . . 73
Vallin & Bjorklund Expires May 26, 2019 [Page 2]
Internet-Draft YANG Alarm Module November 2018
F.2.1. X.733 . . . . . . . . . . . . . . . . . . . . . . . . 73
F.2.2. RFC 3877, the Alarm MIB . . . . . . . . . . . . . . . 73
F.2.3. 3GPP Alarm IRP . . . . . . . . . . . . . . . . . . . 74
F.2.4. G.7710 . . . . . . . . . . . . . . . . . . . . . . . 74
Appendix G. Alarm Usability Requirements . . . . . . . . . . . . 74
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78
1. Introduction
This document defines a YANG [RFC7950] module for alarm management.
The purpose is to define a standardized alarm interface for network
devices that can be easily integrated into management applications.
The model is also applicable as a northbound alarm interface in the
management applications.
Alarm monitoring is a fundamental part of monitoring the network.
Raw alarms from devices do not always tell the status of the network
services or necessarily point to the root cause. However, being able
to feed alarms to the alarm management application in a standardized
format is a starting point for performing higher level network
assurance tasks.
The design of the module is based on experience from using and
implementing available alarm standards from ITU [X.733], 3GPP
[ALARMIRP] and ANSI [ISA182].
1.1. Terminology and Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The following terms are defined in [RFC7950]:
o action
o client
o data tree
o server
The following terms are used within this document:
o Alarm (the general concept): An alarm signifies an undesirable
state in a resource that requires corrective action.
Vallin & Bjorklund Expires May 26, 2019 [Page 3]
Mohali Expires September 5, 2015 [Page 22]
Internet-Draft Mapping of Diversion and History-Info March 2015
| | | <sip:proxyP1>; index=1, | | |
| | | <sip:userB>; index=1.1; rc=1, | | |
| | | <sip:proxyP2; cause=302>; index=1.1.1; mp=1.1 |
| | | | | | | | | |
| | | | | | | |INV E | |
| | | | | | | |----->| |
| | |Diversion: | |
| | |userD; reason=time-of-day; counter=1; privacy=off |
| | |userC; reason=no-answer; counter=1; privacy=full, |
| | |userB; reason=unconditional; counter=1; privacy=off,
| | | History-Info: | |
| | | <sip:proxyP1>; index=1, | |
| | | <sip:userB>; index=1.1; rc=1, | |
| | | <sip:proxyP2; cause=302>; index=1.1.1; mp=1.1 |
| | | | | | | | | |
| | | | | | | | | INV E |
| | | | | | | | |------>|
| | History-Info: | | | | | |
| | <sip:proxyP1>; index=1, | | | | |
| | <sip:userB>; index=1.1; rc=1, | | | |
| | <sip:proxyP2; cause=302>; index=1.1.1; mp=1.1, | |
| | <sip:userC ?privacy=history>; index=1.1.1.0.1, | |
|<sip:userD;cause=408?privacy=none>;index=1.1.1.0.1.1; mp=1.1.1.0.1,|
| |<sip:userE; cause=404>; index=1.1.1.0.1.1.1; mp=1.1.1.0.1.1|
| | | | | | | | | |
| | | | | | | | | |
* Note: The IWF is an interworking function which could be a stand-
alone equipment not defined in this document (it could be a proxy).
7.4. Additional interworking Cases
Even if for particular cases in which both header fields could
coexist, it should be the network local policy responsibility to make
it work together. Here are described some situations and some
recommendations on the behavior to follow.
In the case where there is one network which includes different
nodes, some of them supporting Diversion header field and other ones
supporting History-info header field, there is a problem when any
node handling a message does not know the next node that will handle
the message. This case can occur when the network has new and old
nodes, the older ones using Diversion header field and the more
recent History-Info header field.
While a network replacement may be occurring there will be a time
when both nodes coexist in the network. If the different nodes are
being used to support different subscriber types due to different
Mohali Expires September 5, 2015 [Page 23]
Internet-Draft Mapping of Diversion and History-Info March 2015
node capabilities then the problem is more important. In this case
there is a need to pass both History-Info header field and Diversion
header field within the core network.
These header fields need to be equivalent to ensure that, whatever
the node receiving the message, the correct diversion information is
received. This requires that whatever the received header field,
there is a requirement to be able to compare the header fields and to
convert the header fields. Depending upon the node capability, it
may be possible to make assumptions as to how this is handled.
o If it is known that the older Diversion header field supporting
nodes do not pass on any received History-Info header field then
the interworking becomes easier. If a message is received with
only Diversion header fields then it has originated from an 'old'
node. The equivalent History-Info entries can be created and
these can then be passed as well as the Diversion header field.
o If the node creates a new History-Info header field for a call
diversion, then an additional Diversion header field must be
created.
o If the next node is an 'old' node then the Diversion header field
will be used by that node and the History-Info entries will be
removed from the message when it is passed on.
o If the next node is a new node then the presence of both Diversion
header field and History-Info header field means that interworking
has already occurred and the Diversion and History-Info entries
must be considered equivalent.
o If both nodes pass on both History-Info header field and Diversion
header field but only actively use one, then both types of node
need to perform the interworking and must maintain equivalence
between the header fields. This will eventually result in the use
of Diversion header field being deprecated when all nodes in the
network support History-Info header field.
o If a gap is identified in the History-Info header field by a node
that would create a new entry, it shall add a single index with a
value of "0" prior to adding the appropriate index for the action
to be taken.
Mohali Expires September 5, 2015 [Page 24]
Internet-Draft Mapping of Diversion and History-Info March 2015
8. Backward Compatibility
The backward compatibility aspects are due to the changes on the
History-Info header field evolution from [RFC4244] to [RFC7044]that
are described in section 1.3 of this document. The backawrd
compatibility is taken into account throughout this document for the
interworking with the Diversion header field. More details are
provided in the backward compatibility section of [RFC7044].
9. IANA Considerations
This document makes no request of IANA.
10. Security Considerations
The security considerations in [RFC7044] and [RFC5806] apply.
The privacy considerations described in section 3.2 apply.
The use of Diversion header field or History-Info header field
require to apply the requested privacy and integrity asked by each
diverting user or entity. Without integrity, the requested privacy
functions could be downgraded or eliminated, potentially exposing
identity information. Without confidentiality, eavesdroppers on the
network (or any intermediaries between the user and the privacy
service) could see the very personal information that the user has
asked the privacy service to obscure. Unauthorised insertion,
deletion of modification of those header fields can provide
misleading information to users and applications. A SIP entity that
can provide a redirection reason in a History-Info header field or
Diversion header field should be able to suppress this in accordance
with privacy requirements of the user concerned.
11. Acknowlegements
The editor would like to acknowledge the constructive feedback and
support provided by Steve Norreys, Jan Van Geel, Martin Dolly,
Francisco Silva, Guiseppe Sciortino, Cinza Amenta, Christer Holmberg,
Ian Elz, Jean-Francois Mule, Mary Barnes, Francois Audet, Erick
Sasaki, Shida Schubert, Joel M. Halpern, Bob Braden and Robert
Sparks. Merci a Lionel Morand, Xavier Marjou et Philippe Fouquart.
12. References
Mohali Expires September 5, 2015 [Page 25]
Internet-Draft Mapping of Diversion and History-Info March 2015
12.1. Normative References
[RFC3261] "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3323] "A Privacy Mechanism for the Session Initiation Protocol
(SIP)", RFC 3323, November 2002.
[RFC3326] "The Reason Header Field for the Session Initiation
Protocol (SIP)", RFC 3326, December 2002.
[RFC3966] "The tel URI for Telephone Numbers", RFC 3966, December
2004.
[RFC4244] "An Extension to the Session Initiation Protocol (SIP) for
Request History Information", RFC 4244, November 2005.
[RFC5806] "Diversion Indication in SIP", March 2010.
[RFC7044] "An Extension to the Session Initiation Protocol (SIP) for
Request History Information", RFC 7044, February 2014.
12.2. Informative References
[RFC4458] "Session Initiation Protocol (SIP) URIs for Applications
such as Voicemail and Interactive Voice Response (IVR)",
RFC 4458, April 2006.
[RFC5234] "Augmented BNF for Syntax Specifications: ABNF", RFC 5234,
January 2008.
[RFC6044] "Mapping and Interworking of Diversion Information between
Diversion and History-Info Headers in the Session
Initiation Protocol (SIP)", RFC 6044, October 2010.
[TS_24.604]
3rd Generation Partnership Project, "Technical
Specification Group Core Network and Terminals ;
Communication Diversion (CDIV) using IP Multimedia
(IM)Core Network (CN) subsystem ; Protocol specification
(Release 8), 3GPP TS 24.604", December 2008.
[TS_29.163]
3rd Generation Partnership Project, "Technical
Specification Group Core Network and Terminals ;
Interworking between the IP Multimedia (IM) Core Network
(CN) Subsystem and Circuit Switched (CS) networks (Release
8)", December 2008.
Mohali Expires September 5, 2015 [Page 26]
Internet-Draft Mapping of Diversion and History-Info March 2015
Appendix A. Interworking between Diversion header and Voicemail URI
Voicemail URI is a mechanism described in [RFC4458] to provide a
simple way to transport only one redirecting user address and the
reason why the diversion occurred in the Request-URI of the INVITE
request. This mechanism is mainly used for call diversion to a
voicemail.
A.1. Diversion header field to Voicemail URI
Received:
Diversion: userA-address;reason=user-busy;counter=1;privacy=full
Sent (Voicemail URI created in the R-URI line of the INVITE):
sip: voicemail@example.com;target=userA-address;cause=486 SIP/2.0
Mapping of the Redirection Reason is the same as for History-Info
header field with a default value set to 404.
If the Diversion header field contains more than one Diversion entry,
the choice of the redirecting user information inserted in the URI is
in charge of the network local policy. For example, the choice
criterion of the redirecting information inserted in the URI could be
the destination of forwarded INVITE request (if the voicemail serves
this user or not).
Note: This interworking could be done in addition to the interworking
of the Diversion header field into the History-Info header field.
A.2. Voicemail URI to Diversion header field
In case of real Voicemail, this way of interworking should not
happen. However, if for any reason it occurs, it is recommended to
do it as following:
Received:
INVITE sip: voicemail@example.com;\
target=sip:+33145454500%40example.com;user=phone;\
cause=302 SIP/2.0
Sent in the forwarded INVITE:
Diversion: sip:+33145454500%40example.com;user=phone;
reason=unconditional;counter=1
Mohali Expires September 5, 2015 [Page 27]
Internet-Draft Mapping of Diversion and History-Info March 2015
Author's Address
Marianne Mohali
Orange
38-40 rue du General Leclerc
Issy-Les-Moulineaux Cedex 9 92794
France
Phone: +33 1 45 29 45 14
Email: marianne.mohali@orange.com
Mohali Expires September 5, 2015 [Page 28]