[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

SIPPING Working Group                                       S. Niccolini
Internet-Draft                                                       NEC
Intended status: Informational                                S. Salsano
Expires: May 7, 2009                           Univ. of Rome Tor Vergata
                                                            H. Izumikawa
                                                               KDDI Labs
                                                               R. Lillie
                                                           Motorola Labs
                                                               L. Veltri
                                                          Univ. of Parma
                                                                Y. Kishi
                                                               KDDI Labs
                                                        November 3, 2008

  Requirements for vertical handover of multimedia sessions using SIP

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 7, 2009.


   A vertical handover occurs in heterogeneous networks when a session
   media is moved among different access network technologies within the
   same device.  This document analyses the issue of handling the

Niccolini, et al.          Expires May 7, 2009                  [Page 1]

Internet-Draft         SIP-based vertical handover         November 2008

   vertical handover using the Session Initiation Protocol (SIP) [1].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Scenario for vertical handover . . . . . . . . . . . . . . . .  5
   4.  Requirements for Vertical Handovers  . . . . . . . . . . . . .  6
   5.  Taxonomy of possible approaches  . . . . . . . . . . . . . . .  8
   6.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 10
     10.2.  Informative References  . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 14

Niccolini, et al.          Expires May 7, 2009                  [Page 2]

Internet-Draft         SIP-based vertical handover         November 2008

1.  Introduction

   Let us consider a terminal (hereafter named "Mobile Host" or MH),
   that is possibly equipped with different network interfaces (i.e. a
   subset of WiFi, Bluetooth, GPRS, 3G, 3.5G (HSDPA), fixed Ethernet,
   WiMax).  A user needs to be able to access the Internet using the
   same MH irrespective the type of network it connects to.  Such
   multimode terminals are already in the market, and we will be
   gradually get surrounded by a heterogeneous network where several
   access networks (ANs) supplement each other.  Each interface of the
   MH will receive an IP address from the corresponding AN it connects
   to.  Therefore the mobile host will have a set of different IP
   addresses and will have to select which one to use when running
   multimedia sessions with correspondent terminals.  While the mobile
   host moves, the "selected" interface may become not available due to
   loss of signal, or could suffer high packet loss or packet delay.
   Under these circumstances, the MH would like to switch to another
   interface (using a different IP address) keeping the running sessions
   active, and might adjust the service quality to be optimal depending
   on circumstances.  Even with a single interface the connected access
   network can become not available anymore and the terminal could
   connect to another Access Network (in this case on the same
   technology), which provides a different IP address.  If the switch to
   the new AN is fast enough, the MH could also be interested in keeping
   the running session active.

   This problem can be addressed with many different approaches, at all
   the different levels of the protocol stack from link layer to
   application layer.  For a review and comparison of these different
   approaches, see for example [15] and [14].  We are interested here in
   "application level" mobility solutions.  The main advantage of
   application level mobility solutions is that they do not require any
   support at the networking level and below from the different access
   networks, which only needs to provide plain IP connectivity.
   Application level mobility can conduct flexible mobility management,
   which is another advantage.  Within IETF, discussions on using SIP
   for mobility management date back several years ago and have been
   mostly carried on in SIPPING WG.  For example [11] analysed
   preliminary requirements and identified issues that need to be
   resolved in order to develop a mobility management mechanism in a SIP
   environment. .  Furthermore, session mobility using SIP [8] has been
   discussed in SIPPING WG, and is now awaiting processing and
   publishing as RFC.

   This document addresses issues and requirements regarding a SIP based
   "application level" mobility solution, focusing on "terminal
   mobility".  Although "terminal mobility" could be considered as a
   sub-set of "session mobility", we believe that some requirements

Niccolini, et al.          Expires May 7, 2009                  [Page 3]

Internet-Draft         SIP-based vertical handover         November 2008

   (e.g. vertical handovers, fast switching) are not adequately covered
   by the mobility features of current SIP specifications and therefore
   they need a careful consideration within the SIPPING WG.

   The relevance of this topic is also confirmed by the ongoing work
   within 3GPP on "Voice Call Continuity" [17] and "Multimedia Session
   Continuity" [18], which is providing specification of vertical
   handover solutions using SIP.  A discussion of mobility requirements
   and solution within SIPPING WG provides the chance to consider this
   3GGP work.

2.  Terminology

   This section presents a few terms used throughout the document.

   o  Vertical handover: A vertical handover refers to changing a MH's
      point of attachment between different types of access networks,
      e.g.  GPRS and WiFi.  The feature of a vertical handover is that
      the transmission rate and latency may well differ significantly
      before and after handover, respectively.

   o  Network level mobility: Network level mobility refers to managing
      an MH's mobility at the network layer.  Mobile IP (MIP) [2] and
      Mobile IPv6 (MIPv6) [3] are well-known as network level mobility.
      One of the merits of network level mobility is making the mobility
      of an MH transparent to an application by keeping the same IP
      address.  This type of mobility management is useful to run
      existing applications.  However, an ubiquitous deployment of MIP/
      MIPv6 is needed if a MH's mobility is globally supported.  In
      addition, it is difficult for an application to recognize an
      available bandwidth and delay before or during handoff and to
      adjust a transmitting rate or buffer space to a target network
      since network level mobility makes the MH's mobility transparent
      to the upper layer.

   o  Application level mobility: Application level mobility refers to
      managing an MH's mobility at the application layer.  SIP mobility
      [7] is well-known as application level mobility.  Application
      level mobility has its merits in terms of its ease of deployment.
      This does not require whole networks to be changed.  Therefore,
      the mobility support can be more and more rapidly deployable using
      application level mobility.  Furthermore, SIP has an affinity for
      applications, which can make handoff more flexible.  The feature
      can fit heterogeneous networks where an available bandwidth and
      delay may well differ significantly among access networks.

Niccolini, et al.          Expires May 7, 2009                  [Page 4]

Internet-Draft         SIP-based vertical handover         November 2008

   o  Terminal mobility: Terminal Mobility allows a device to move
      between IP subnets, while continuing to be reachable for incoming
      requests and maintaining sessions across subnet changes.
      (Definition from [7])

   o  Session mobility: Session mobility allows a user to maintain a
      media session even while changing terminals.  (Definition from

3.  Scenario for vertical handover

   In this document, we focus on Terminal Mobility.  The figure below
   shows a Mobile Host that wants to communicate with a "Correspondent
   Host" (CH).  The Mobile Host can connect to different Access Networks
   (AN1, AN2, AN3 are represented in the figure).  The different ANs
   could have different wireless or wired technologies and difference
   bandwidth/delay, and the Mobile Host could be connected to more than
   one Access Network at the same time if it has more than one physical
   network interface.  Note that the Access Networks can provide public
   or private addresses to the mobile host (in most typical scenarios
   the Access Networks are likely to provide private IP addresses).  For
   example in the figure below AN 1 and AN 3 provide a private address
   (as shown by the NAT box), while AN2 provides a public address.
   Similarly, the Correspondent Host can have a public address (like CH
   1 in the figure) or a private IP address (like CH 2 in the figure).

                               |  AN1  |-----+
                           ----|       | NAT |                +--------+
                          /    +-------+-----+                |Corresp.|
             +-------+                         __________     | Host 1 |
             | Mobile|         +-------+      /          \    +--------+
             | Host  |         |  AN2  |     /            \
             +-------+     ----|       |    |   INTERNET   |
                               + - - - +     \            /
                          \    +-------+                      +--------+
                           ----|  AN3  |-----+          +-----|Corresp.|
                               |       | NAT |          | NAT | Host 2 |
                               +-------+-----+          +-----+--------+

           Figure 1 - Network architecture for vertical handover

   The goal of the handover mechanism is to let the MH roam among
   different Access Networks in a seamless way.  Therefore we are
   addressing the issue of "Terminal Mobility" as defined in previous

Niccolini, et al.          Expires May 7, 2009                  [Page 5]

Internet-Draft         SIP-based vertical handover         November 2008

   section.  The mobility management mechanism should consider the
   roaming of the MH both "off call" and during an active call.  The MH
   should be able to dynamically choose among the available ANs the one
   that better suits its needs (e.g. perceived quality of media flows
   and cost) in a given moment.  It is important to notice that this
   draft does not address the criteria and tools for selection of the
   "best" access network, it only details the issues and the
   requirements regarding the mobility management and handover execution

4.  Requirements for Vertical Handovers

   In this session we discuss a set of requirements that a mobility
   management solution based on SIP should have.  The requirements are
   divided into two types, i.e., mandatory requirements and optional

   Mandatory Requirements

   o  The solution should take care of handover as fast as possible.
      The goal is to provide a "seamless" handover with no perception
      from the user point of view.  If it is not possible to provide a
      truly seamless solution, the impairment should be minimized.  For
      example, voip application is used to evaluate for the performance
      of SIP-based terminal mobility in [9] and also video-phone is used
      in [13].  According to the ITU requirement[19], one-way delay and
      packet loss rate for conversational voice and video-phone are
      required to be less than 150 ms and 3%, and 150 ms and 1%,

   o  The handover solution should not require a support in the
      different access network.  The access networks are only required
      to provide IP connectivity (either with public or private
      addresses) for the forwarding of signalling SIP packets and media
      RTP packets.

   o  Correspondent Host (CH) (which in general are not moving, but they
      are communicating with a moving terminal) should be a basic User
      Agent (UA) which only has basic SIP capabilities.  If this
      requirement is not fulfilled there is the need to change all SIP
      terminals to support the handovers of Mobile Host.

   o  The handover solution should be compatible with NATted networks,
      i.e. it should interoperate gracefully with NAT traversal
      mechanisms for SIP signaling and for session media flows.

   Optional Desirable Requirements

Niccolini, et al.          Expires May 7, 2009                  [Page 6]

Internet-Draft         SIP-based vertical handover         November 2008

   o  The solution may support a "forward handover" (i.e. in which all
      the procedure is performed on the new target Access Network).
      This is important if the connection on the old Access Network is
      suddenly broken.  If possible (i.e. if the connection with the old
      access network does not break suddenly) the solution could exploit
      the communication on the old access network in order to better
      control the handover procedure.  Soft handovers (i.e. where the
      two active connections can be exploited in the same moment to send
      the session data) could be exploited.

   o  The switch of the "active" interface during a SIP transaction may
      be supported.  As an example the terminal should be able to send
      (receive) an INVITE on the currently active interface, switch to
      another interface and receive (send) the 200 OK on the other

   o  Decoupling of "user level" registration and mobility and "terminal
      level" mobility may be allowed.  As an example a user with AOR
      "sip:user@domain.com" should be allowed to use different terminals
      (i.e.  Mobile Hosts supporting the handover solutions as well as
      normal SIP terminals).  These terminals can be used in sequence or
      at the same time depending on the capability of his own "home"
      registrar/proxy server, and this is independent of the vertical
      handover solution which takes care of the mobility of only one
      specific Mobile Host.  A concrete example for this requirement is
      to support a user "sip:user@domain.com" who owns three Mobile
      Hosts (one could be his phone, one his PDA, one his laptop) and
      two fixed terminals (his desktop and his home VoIP phone).  The
      vertical handover solution takes care of the mobility of the
      phone, PDA and laptop as three separate Mobile Hosts (which can
      also be all active in the same time).

   o  Providing privacy with respect to user location and user movements
      would be preferable.

   o  Existing user agents for the Mobile Host may inter-work with the
      handover procedure without the need to be updated.  It would be
      desirable to reuse existing SIP clients (User Agents) without
      updating them to support the terminal mobility.

   o  It is desirable that the service quality is adjusted to optimal
      levels according to the access network after every handover.

   o  Non-RTP media such as IM or file transfer using MSRP may be

Niccolini, et al.          Expires May 7, 2009                  [Page 7]

Internet-Draft         SIP-based vertical handover         November 2008

5.  Taxonomy of possible approaches

   The application level terminal mobility solutions based on SIP can be
   classified in "Correspondent host based" or "Intermediate Element
   based".  In addition, a session mobility is introduced just for

   o  Correspondent Host based terminal mobility solutions

   RFC 3261 [1] has a built in mechanism for mobility management.  The
   "off-call" mobility management consists in the Registration process.
   The "on-call" handover is performed using RE-INVITE messages towards
   the Corresponding Node [7].  No intermediate entities are directly
   involved in the handover process.  This has the advantage that no
   additional procedures for the handover need to be implemented in
   intermediate elements, and that there is no additional load in the
   networks due to the handovers.  On the other hand, the procedure
   requires that the Corresponding Node (which in general is not a
   mobile host) supports the RE-INVITE mechanism.  A second drawback is
   that the handover delay is directly proportional to the end-to-end
   delay, and this could be higher with respect to the delay occurring
   between a mobile node and an intermediate element.

   o  Intermediate Element based terminal mobility solutions

   In order to overcome the drawbacks of the Correspondent Host based
   solutions, "intermediate" entities that take an active role in the
   handover can be introduced.  Several proposals can be found in the
   literature, but to our knowledge no internet draft has been proposed
   in this respect.  Hereafter we mention some of the existing
   proposals.  In [6], intermediate entities are used only to speed up
   the handover process, but the handover procedure still involves the
   Corresponding Node as well.  A similar approach is followed in [12],
   which also deals with location based selection of the "optimal"
   intermediate entity and of wireless access points.  In [10] the
   intermediate entities fully handle the user mobility, hiding the
   mobility to the Corresponding Nodes.  In [13], the intermediate
   entities are used to support MH's mobility as well as adjusting
   service quality to the MH's target access network. [16] also
   describes different ways "intermediate element"-based approach can
   expedite handover for single-interface-based terminals.

   o  Session mobility solutions

   According to [8] session mobility is the transfer of media of an
   ongoing communication session from one device to another. [5], based
   on the previous work in [7] has defined a framework for session
   mobility that allows a mobile node to discover available devices and

Niccolini, et al.          Expires May 7, 2009                  [Page 8]

Internet-Draft         SIP-based vertical handover         November 2008

   to include them in an active session. [5] has demonstrated the
   suitability of employing either 3PCC (3PCC) [4] or SIP's REFER [5]
   method as suitable mechanisms for session mobility between mobile

   The problem of session mobility is more general and more complex than
   the problem of terminal mobility that is addressed by this
   requirement analysis.  It is likely that a solution for the session
   mobility problem can also solve the terminal mobility problem, but it
   also needs to consider several aspects that are not relevant to
   terminal mobility.  Just to give two examples: 1) device discovery;
   2) signaling procedures to communicate the intention or need to
   transfer the session from the original device and the target devices.
   These two aspects are not needed in a solution for terminal mobility,
   as all the network interfaces are local to the terminal and they do
   not need to be discovered nor there is the need to communicate the
   session transfer from one interface to another.  On the other hand,
   there are some specific requirements that could be taken into
   consideration in terminal mobility.  One example is the avoidance of
   media disruption during the handover.  The gap of the media stream in
   terminal mobility case (on the same terminal) would cause more severe
   degradation in the user's experience than that in the session
   mobility case.  Such gap should be made minimum or avoided during the
   handover in terminal mobility.

   For the above reason, we believe that requirements for terminal
   mobility should be addressed in a separate context than session
   mobility.  Obviously solutions for session mobility could become a
   part of the solution for terminal mobility

6.  Conclusions

   As a concluding remark, we believe that it is important to consider a
   new solution for vertical handover that meets the set of requirements
   that has been analysed.  This solution will help providing seamless
   handover to SIP based application with a better performance and
   overcoming some shortcomings of the current solution based on [1].

7.  Security considerations

   The security considerations should be taken into account in the
   design of the handover solution, so that no new additional security
   issues will be introduced.

Niccolini, et al.          Expires May 7, 2009                  [Page 9]

Internet-Draft         SIP-based vertical handover         November 2008

8.  IANA Considerations

   This memo includes no request to IANA.

9.  Acknowledgments

   The authors would like to thank a number of people that recently
   contributed to the development of this draft in a more clear
   direction pointing out the issues that need to be addressed to
   advance this document.  Acknowledgement go to people in the SIPPING
   working group, including: Ashutosh Dutta, Salvatore Loreto, Henning
   Schulzrinne and Henry Sinnreich.

10.  References

10.1.  Normative References

   [1]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
         Session Initiation Protocol", RFC 3261, June 2002.

   [2]   Perkins, C., "Mobility Support in IPv6", RFC 3344, August 2002.

   [3]   Johnson, D., Perkins, C., and J. Arkko, "IP Mobility Support
         for IPv4", RFC 3775, June 2004.

   [4]   Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
         "Best Current Practices for Third Party Call Control (3pcc) in
         the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
         April 2004.

   [5]   Sparks, R., "The Session Initiation Protocol (SIP) Refer
         Method", RFC 3515, April 2003.

10.2.  Informative References

   [6]   Banerjee, N., Acharya, A., and S. Das, "Seamless SIP-Based
         Mobility for Multimedia Applications", IEEE Network , March/
         April 2006.

   [7]   Schulzrinne, H. and E. Wedlund, "Application-Layer Mobility
         Using SIP", ACM Mobile Computing and Communications
         Review Vol.4, No.3, July 2000.

   [8]   Shacham, R., "Session Initiation Protocol (SIP) Session
         Mobility", draft-shacham-sipping-session-mobility-05 (work in

Niccolini, et al.          Expires May 7, 2009                 [Page 10]

Internet-Draft         SIP-based vertical handover         November 2008

         progress), November 2007.

   [9]   Salsano, S.,  Veltri , L.,  Polidoro , A., and A.  Ordine ,
         "Architecture and testbed implementation of vertical handovers
         based on SIP Session Border Controllers", Wireless Personal
         Communications, Springer , November 2007.

   [10]  Salsano, S., Mingardi, C., Niccolini, S., Polidoro, A., and L.
         Veltri, "SIP-based Mobility Management in Next Generation
         Networks", IEEE Wireless Communication , April 2008.

   [11]  Vakil, F., Dutta, A., Chen, J-C., Baba, S., Nakajima, N.,
         Shobatake, Y., and H. Schulzrinne, "Mobility Management in a
         SIP Environment Requirements, Functions and Issues",
         draft-itsumo-sip-mobility-req-02.txt (work in progress),
         December 2000.

   [12]  Tsiakkouris, S. and I. Tsiakkouris, "PROFITIS: architecture for
         location-based vertical handovers supporting real-time
         applications", 25th IEEE International Performance, Computing,
         and Communications Conference (IPCCC 2006), April 2006.

   [13]  Izumikawa, H., Fukuhara, T., Matsunaka, T., and K. Sugiyama,
         "User-centric Seamless Handover Scheme for Realtime
         Applications", IEEE Internation Symposium on Personal, Indoor
         and Mobile Radio Communications (PIMRC'07), September 2007.

   [14]  Le, D., Fu, X., and D. Hogrefe, "A review of Mobility Support
         Paradigms for the Internet", IEEE Communications Surveys &
         Tutorials Vol.8, No.1, 1st quarter 2006.

   [15]  Dutta, A., Lyles, B., Schulzrinne, H., Chiba, T., Yokota, H.,
         and A. Idoue, "Generalized Modeling Framework for Handoff
         Analysis", 18th Annual IEEE International Symposium on
         Personal, Indoor and Mobile Radio Communications (PIMRC 2007),
         September 2007.

   [16]  Dutta, A., Madhani, S., Chen, W., and H. Schulzrinne, "Fast-
         handoff Schemes for Application Layer Mobility Management",
         15th Annual IEEE International Symposium on Personal, Indoor
         and Mobile Radio Communications (PIMRC 2004), September 2004.

   [17]  3GPP, "Voice call continuity between Circuit Switched (CS) and
         IP Multimedia Subsystem (IMS) Study", 3GPP TR 23.806 7.0.0,
         December 2005.

   [18]  3GPP, "Feasibility study on multimedia session continuity;
         Stage 2", 3GPP TR 23.893 8.0.0, June 2008.

Niccolini, et al.          Expires May 7, 2009                 [Page 11]

Internet-Draft         SIP-based vertical handover         November 2008

   [19]  ITU-T, "ITU-T G.1010 End-user multimedia QoS categories", 2001.

Authors' Addresses

   Saverio Niccolini
   Network Laboratories, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115

   Phone: +49 (0) 6221 43 42 118
   Email: saverio.niccolini@netlab.nec.de
   URI:   http://www.netlab.nec.de

   Stefano Salsano
   DIE, University of Rome "TorVergata"
   Via Politecnico, 1
   Rome  00156

   Phone: +39 06 7259 7770
   Email: stefano.salsano@uniroma2.it
   URI:   http://netgroup.uniroma2.it/Stefano_Salsano

   Haruki Izumikawa
   KDDI Labs
   Postfach 330440
   Bremen  28334

   Phone: +49-421/21863908
   Email: izumikawa@kddilabs.jp

   Ross Lillie
   Motorola Labs
   1301 East Algonquin Road, IL02/2240
   Schaumburg, IL  60196

   Phone: +1 847 576 0012
   Email: ross.lillie@motorola.com

Niccolini, et al.          Expires May 7, 2009                 [Page 12]

Internet-Draft         SIP-based vertical handover         November 2008

   Luca Veltri
   DII, University of Parma
   Parco Area delle Scienze 181/A
   Parma  43100

   Phone: +39 0521 90 5768
   Email: luca.veltri@unipr.it
   URI:   http://www.tlc.unipr.it/veltri

   Yoji Kishi
   KDDI Labs
   2-1-15 Ohara
   Fujimino  356-8502

   Email: kishi@kddilabs.jp

Niccolini, et al.          Expires May 7, 2009                 [Page 13]

Internet-Draft         SIP-based vertical handover         November 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Niccolini, et al.          Expires May 7, 2009                 [Page 14]

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/