Requirements for Signaling Protocols
RFC 3726

 
Document Type RFC - Informational (April 2004; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3726 (Informational)
Telechat date
Responsible AD Allison Mankin
Send notices to <john.loughney@nokia.com>
Network Working Group                                    M. Brunner, Ed.
Request for Comments: 3726                                           NEC
Category: Informational                                       April 2004

                 Requirements for Signaling Protocols

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document defines requirements for signaling across different
   network environments, such as across administrative and/or technology
   domains.  Signaling is mainly considered for Quality of Service (Qos)
   such as the Resource Reservation Protocol (RSVP).  However, in recent
   years, several other applications of signaling have been defined.
   For example, signaling for label distribution in Multiprotocol Label
   Switching (MPLS) or signaling to middleboxes.  To achieve wide
   applicability of the requirements, the starting point is a diverse
   set of scenarios/use cases concerning various types of networks and
   application interactions.  This document presents the assumptions
   before listing the requirements.  The requirements are grouped
   according to areas such as architecture and design goals, signaling
   flows, layering, performance, flexibility, security, and mobility.

Brunner                      Informational                      [Page 1]
RFC 3726          Requirements for Signaling Protocols        April 2004

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
       1.1.  Keywords . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology. . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Problem Statement and Scope. . . . . . . . . . . . . . . . . .  6
   4.  Assumptions and Exclusions . . . . . . . . . . . . . . . . . .  8
       4.1.  Assumptions and Non-Assumptions. . . . . . . . . . . . .  8
       4.2.  Exclusions . . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
       5.1.  Architecture and Design Goals. . . . . . . . . . . . . . 11
             5.1.1.  NSIS SHOULD Provide Availability Information
                     on Request . . . . . . . . . . . . . . . . . . . 11
             5.1.2.  NSIS MUST be Designed Modularly. . . . . . . . . 11
             5.1.3.  NSIS MUST Decouple Protocol and Information. . . 12
             5.1.4.  NSIS MUST Support Independence of Signaling and
                     Network Control Paradigm . . . . . . . . . . . . 12
             5.1.5.  NSIS SHOULD be Able to Carry Opaque Objects. . . 12
       5.2.  Signaling Flows. . . . . . . . . . . . . . . . . . . . . 12
             5.2.1.  The Placement of NSIS Initiator, Forwarder, and
                     Responder Anywhere in the Network MUST be
                     Allowed. . . . . . . . . . . . . . . . . . . . . 12
             5.2.2.  NSIS MUST Support Path-Coupled and MAY Support
                     Path-Decoupled Signaling . . . . . . . . . . . . 13
             5.2.3.  Concealment of Topology and Technology
                     Information SHOULD be Possible . . . . . . . . . 13
             5.2.4.  Transparent Signaling Through Networks SHOULD be
                     Possible . . . . . . . . . . . . . . . . . . . . 13
       5.3.  Messaging. . . . . . . . . . . . . . . . . . . . . . . . 13
             5.3.1.  Explicit Erasure of State MUST be Possible . . . 13
             5.3.2.  Automatic Release of State After Failure MUST be
                     Possible . . . . . . . . . . . . . . . . . . . . 14
             5.3.3.  NSIS SHOULD Allow for Sending Notifications
                     Upstream . . . . . . . . . . . . . . . . . . . . 14
             5.3.4.  Establishment and Refusal to set up State MUST
                     be Notified. . . . . . . . . . . . . . . . . . . 15
             5.3.5.  NSIS MUST Allow for Local Information Exchange . 15
       5.4.  Control Information. . . . . . . . . . . . . . . . . . . 16
             5.4.1.  Mutability Information on Parameters SHOULD be
                     Possible . . . . . . . . . . . . . . . . . . . . 16
             5.4.2.  It SHOULD be Possible to Add and Remove Local
                     Domain Information . . . . . . . . . . . . . . . 16
             5.4.3.  State MUST be Addressed Independent of Flow
                     Identification . . . . . . . . . . . . . . . . . 16
             5.4.4.  Modification of Already Established State SHOULD
                     be Seamless. . . . . . . . . . . . . . . . . . . 16
             5.4.5.  Grouping of Signaling for Several Micro-Flows
                     MAY be Provided. . . . . . . . . . . . . . . . . 17
Show full document text