Requirements for Header Compression over MPLS
RFC 4247

Document Type RFC - Informational (November 2005; 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 4247 (Informational)
Telechat date
Responsible AD Allison Mankin
Send notices to csp@csperkins.org, magnus.westerlund@ericsson.com, gash@research.att.com
Network Working Group                                             J. Ash
Request for Comments: 4247                                      B. Goode
Category: Informational                                          J. Hand
                                                                    AT&T
                                                                R. Zhang
                                                              BT Infonet
                                                           November 2005

             Requirements for Header Compression over MPLS

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 (2005).

Abstract

   Voice over IP (VoIP) typically uses the encapsulation
   voice/RTP/UDP/IP.  When MPLS labels are added, this becomes
   voice/RTP/UDP/IP/MPLS-labels.  For an MPLS VPN, the packet header is
   typically 48 bytes, while the voice payload is often no more than 30
   bytes, for example.  Header compression can significantly reduce the
   overhead through various compression mechanisms, such as enhanced
   compressed RTP (ECRTP) and robust header compression (ROHC).  We
   consider using MPLS to route compressed packets over an MPLS Label
   Switched Path (LSP) without compression/decompression cycles at each
   router.  This approach can increase the bandwidth efficiency as well
   as processing scalability of the maximum number of simultaneous flows
   that use header compression at each router.  In this document, we
   give a problem statement, goals and requirements, and an example
   scenario.

Ash, et al.                  Informational                      [Page 1]
RFC 4247     Requirements for Header Compression over MPLS November 2005

Table of Contents

   1. Introduction ....................................................2
   2. Problem Statement ...............................................3
      2.1. Specification of Requirements ..............................4
   3. Goals and Requirements ..........................................5
   4. Candidate Solution Methods and Needs ............................6
   5. Example Scenario ................................................7
   6. Security Considerations .........................................8
   7. Normative References ............................................8
   8. Informative References ..........................................9
   9. Acknowledgements ...............................................10

1.  Introduction

   Voice over IP (VoIP) typically uses the encapsulation
   voice/RTP/UDP/IP.  When MPLS labels [MPLS-ARCH] are added, this
   becomes voice/RTP/UDP/IP/MPLS-labels.  For an MPLS Virtual Private
   Network (VPN) (e.g., [MPLS-VPN]), the packet header is at least 48
   bytes, while the voice payload is often no more than 30 bytes, for
   example.  The interest in header compression (HC) is to exploit the
   possibility of significantly reducing the overhead through various
   compression mechanisms, such as with enhanced compressed RTP [ECRTP]
   or robust header compression [ROHC], and also to increase scalability
   of HC.  We consider using MPLS to route compressed packets over an
   MPLS Label Switched Path (LSP) without compression/decompression
   cycles at each router.  Such an HC over MPLS capability can increase
   bandwidth efficiency as well as the processing scalability of the
   maximum number of simultaneous flows that use HC at each router.

   To implement HC over MPLS, the ingress router/gateway would have to
   apply the HC algorithm to the IP packet, the compressed packet routed
   on an MPLS LSP using MPLS labels, and the compressed header would be
   decompressed at the egress router/gateway where the HC session
   terminates.  Figure 1 illustrates an HC over MPLS session established
   on an LSP that crosses several routers, from R1/HC --> R2 --> R3 -->
   R4/HD, where R1/HC is the ingress router where HC is performed, and
   R4/HD is the egress router where header decompression (HD) is done.
   HC of the RTP/UDP/IP header is performed at R1/HC, and the compressed
   packets are routed using MPLS labels from R1/HC to R2, to R3, and
   finally to R4/HD, without further decompression/recompression cycles.
   The RTP/UDP/IP header is decompressed at R4/HD and can be forwarded
   to other routers, as needed.

Ash, et al.                  Informational                      [Page 2]
RFC 4247     Requirements for Header Compression over MPLS November 2005

                    _____
                   |     |
                   |R1/HC| Header Compression (HC) Performed
Show full document text