[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: (draft-berger-mpls-hdr-comp) 00
Network Working Group Lou Berger
Internet Draft LabN Consulting, LLC
Expiration Date: January 2001
Jason Jeffords
Integral Access Inc.
July 2000
MPLS/IP Header Compression
draft-ietf-mpls-hdr-comp-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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."
To view the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in an Internet-Drafts Shadow
Directory, see http://www.ietf.org/shadow.html.
Abstract
This document describes a method for compressing the headers of IP
datagrams that are being transported over MPLS. This work extends
the existing IP and IP/UDP/RTP header compression techniques, as
defined in [RFC2507] and [RFC2508], to operate over and to compress
MPLS label stack entries.
Berger & Jeffords [Page 1]
Internet Draft draft-ietf-mpls-hdr-comp-00.txt July 2000
Changes from previous version:
o Changed name to draft-ietf-mpls-hdr-comp-00.txt.
o Changed name of 'N-bit' to 'P-bit' to avoid naming collision.
1. Introduction
IP and IP/UDP/RTP header compression, which is defined in [RFC2507]
and [RFC2508], reduces header overhead and is particularly useful on
lower speed links. The current header compression definition relies
on IP datagrams being carried directly over a link layer protocol,
such as PPP [STD51]. With the introduction of MPLS [LABELS], one or
more MPLS headers, which are called label stack entries, may be
present between the IP and link layer headers. Since the header
following the link layer header is no longer IP, the existing
compression techniques will not operate. Clearly delivering header
compression when using MPLS on lower speed links is desirable.
This document presents one method for providing header compression
while running over MPLS. The presented method incrementally builds
on the header compression techniques defined in [RFC2507] and
[RFC2508]. It makes use of the same basic mechanisms and continues
to provide compression on a link-by-link basis. It preserves the
ability to compress all headers, including multiple MPLS label stack
entries, into the same space when MPLS EXP bits remain constant.
This is 2-4 bytes for MPLS/IP/UDP/RTP header compression. It also
co-exists with standard IP, IP/TCP and IP/UDP/RTP header compression
running on the same link.
Familiarity with [RFC2507], [RFC2508] and [RFC1144] is encouraged as
the material presented in those documents is not repeated in this
document and their principals and techniques are leveraged.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. Compression Method Overview
The defined compression method reuses the compression techniques and
formats defined for IP and IP/UDP/RTP compression. IP and IP/UDP/RTP
compression relies on many header fields not changing per packet over
the life of the session, or some fields differing from packet to
packet by only a constant value. By maintaining both the
uncompressed header and the first-order differences in the session
state shared between the compressor and decompressor, all that must
Berger & Jeffords [Page 2]
Internet Draft draft-ietf-mpls-hdr-comp-00.txt July 2000
be communicated is an indication that the second-order difference was
zero. The decompressor can then reconstruct the original header
without any loss of information simply by using the packet length
indicated by the link-level protocol and by adding the first-order
differences to the saved uncompressed header as each compressed
packet is received.
The same compression techniques can be used on MPLS label stack
entries. All fields within a stack entry other than the EXP field
will typically remain constant over the life of a session. When a
label stack is used, i.e., there is more than one stack entry, the
number of stack entries and the label values of each will also remain
constant. To support MPLS header compression, the number of stack
entries and each entry's label is added to the session context.
As with the previous techniques, the compressor and decompressor must
maintain state per session context. Likewise, multiple session
contexts should be maintained. In addition to the new MPLS related
information, the session context contains the combination of the IP
source and destination addresses, the TCP or UDP source and
destination ports, and for RTP the SSRC field. As with IP/UDP/RTP
compression, a compressor implementation might use a hash function on
these fields to index a table of stored session contexts. The
compressed packet continues to carry a small integer, called the
session context identifier or CID, to indicate in which session
context that packet should be interpreted. Packets containing full
headers and a CID are transmitted to initiate compression and to keep
the decompressor synchronized. The decompressor can use the CID to
index its table of stored session contexts directly. The CID
together with any header fields that differ by a non-constant value
are all that must be conveyed in order for the decompressor to
reconstruct the full original MPLS, IP, TCP, UDP and RTP headers.
Note that the existing TCP and non-TCP CID spaces are reused for MPLS
encapsulated traffic.
If not explicitly mentioned, all the conditions and restrictions
documented in [RFC2507] and [RFC2508] apply to this document. For
example, this includes the restrictions on handling of fragmented IP
packets, and the need for most compressor implementations to maintain
a "negative cache" of packet streams that have failed to compress as
RTP packets.
Other methods for supporting IP and IP/UDP/RTP header compression
over MPLS are possible and some where considered. One alternative
worth noting is adapting the existing header compression techniques
to operate directly over MPLS without any MPLS header compression.
This method was discounted for a couple of reasons. The first was
that MPLS headers do not typically carry a packet type code. Such
Berger & Jeffords [Page 3]
Internet Draft draft-ietf-mpls-hdr-comp-00.txt July 2000
codes could be carried by assigning special meaning to the EXP field
or even the label field. It was decided that such assignment was
undesirable due to possible collision with Diff-Serv usage of the EXP
field and not wanting to subdivide the label field. The second and
more important reason for not adapting compression to operate over
MPLS was simply to gain extra efficiency by enabling the compression
of the MPLS label stack.
3. MPLS/IP Header Compression
MPLS headers, i.e., label stack entries, are carried between the IP
header and the link layer header. The number of stack entries and
the label values of each will remain constant through the life of a
session. Data flows that have different number of stack entries or
different label values are always considered to be different
sessions. The only part of a stack entry that may change during a
session is the EXP field, and this is only the case for some
sessions.
To support a session that uses MPLS headers, the compressor and
decompressor must synchronize, on a per MPLS session basis, on the
number of stack entries and on the contents of each entry. Once a
compressor and decompressor are synchronized on the MPLS headers, the
headers need not be resent. For the cases where the EXP field my
regularly change, the changed EXP fields must be conveyed per packet.
When multiple stack entries are present, more than one EXP field may
change in a label stack.
Other than the initial synchronization of MPLS information and
possible EXP field support, the previously defined header compression
techniques can be reused with little or no modification. The primary
modifications required are to session context information, and the
communication of uncompressed MPLS headers.
As with IP and IP/UDP/RTP compression, there is a separate session
context for each MPLS/IP packet stream. The number of session
contexts to be maintained MAY continue to be negotiated between the
compressor and decompressor. The support of MPLS/IP compression MUST
be negotiated or configured. The following information is added to
the shared information in each context, as defined in [RFC2507] and
[RFC2508]:
o The number of stack entries.
o The full MPLS stack.
o Whether EXP changes are being supported. This may change over
Berger & Jeffords [Page 4]
Internet Draft draft-ietf-mpls-hdr-comp-00.txt July 2000
the life of a session.
To communicate this new shared information, a new packet format is
defined:
o FULL_MPLS_HEADER - communicates the uncompressed MPLS stack
plus any following headers and data to establish the
uncompressed header state in the decompressor for a particular
context. The FULL_MPLS_HEADER packet also carries the 8- or
16-bit session context identifier and other previously defined
fields to establish synchronization between the compressor and
decompressor.
Also to eliminate the possibility of interpreting an MPLS session as
non-MPLS sessions in the face of certain loss conditions, the
following packet format is defined:
o COMPRESSED_MPLS - indicates a packet with a compressed MPLS
header. This packet contains a full IP header. It is used in
place of the FULL_HEADER packet.
Assignments of numeric codes for these packet formats for PPP [STD51]
are to be made by the Internet Assigned Numbers Authority.
3.1. FULL_MPLS_HEADER Packet Format
The FULL_MPLS_HEADER packet is used to associate a compression
context ID with full MPLS, IP, TCP or UDP and RTP headers, or to
update the contents of some of those headers. It is only used when
one or more MPLS stack entries are preset.
As with the existing IP and IP/UDP/RTP compression, the format of the
FULL_MPLS_HEADER packet is the same as that of the original packet.
The FULL_MPLS_HEADER packet differs from the corresponding normal
MPLS/IPv4 or MPLS/IPv6 packet in that it must also carry the
compression context ID and other previously defined compression
related fields. The compression related information in a
FULL_MPLS_HEADER packet differs from the information defined in
Section 5.3.2 of [RFC2507] and Section 3.3.1 of [RFC2508] in that it
also contains an MPLS related flag. The flag, called the NoEXP or
"P" bit, indicates when the EXP bits will NOT be conveyed in every
compressed packet. The position of the compression related
information is unchanged and is specified in Section 5.3.2 of
[RFC2507].
Berger & Jeffords [Page 5]
Internet Draft draft-ietf-mpls-hdr-comp-00.txt July 2000
The definition of the compression related information carried in a
FULL_MPLS_HEADER packet is:
For MPLS/IP/UDP sessions [RFC 2508, Section 3.3.1]
For 8-bit context ID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1| Generation| CID | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| 0 | seq | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For 16-bit context ID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1| Generation|P| 0 | seq | First length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CID | Second length field
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For MPLS/IP/TCP sessions [RFC 2507, Section 5.3.1]
Use of first length field:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length field | LSB of pkt nr | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Use of second length field if available:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field | MSB of pkt nr |P| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Berger & Jeffords [Page 6]
Internet Draft draft-ietf-mpls-hdr-comp-00.txt July 2000
For MPLS/non-TCP sessions [RFC 2507, Section 5.3.1]
For non-TCP headers with 8-bit CID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field |0|D| Generation| CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Use of second length field if available:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field |P| 0 | Data (if D=1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Full non-TCP headers with 16-bit CID:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
First length field |1|D| Generation|P|Data (if D=1)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Second length field | CID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The only new field introduced in the above formats is the P-bit. The
P-bit, when set, indicates that the EXP fields in all present MPLS
label stack entries will remain constant. When not set, i.e., is
zero (0), one or more EXP fields may change on a packet-by-packet
basis. In this case, a new EXP Compression field is included in all
compressor to decompressor packets defined in [RFC2507] and
[RFC2508]. See Section 3.5 for more details. Note that in the 8-bit
CID cases the P-bit is carried in the second length field. When the
second length field is not available, the P-bit is not carried and
and the use of the EXP Compression field is implied.
With the exception of the P-bit all fields have the same meaning and
use as with existing IP and IP/UDP/RTP compression. Processing of a
MPLS_FULL_HEADER parallels the processing of a FULL_HEADER packet.
As with the FULL_HEADER packet, a receiver of a MPLS_FULL_HEADER
packet stores the complete set of headers into the context selected
by the context ID. The other compression related information is also
stored in the context, thereby resynchronizing the decompressor to
the compressor.
MPLS_FULL_HEADER packets are sent for new sessions, after the receipt
of a CONTEXT_STATE message indicating that synchronization has been
lost for the associated CID, and periodically as called for in
[RFC2507] and [RFC2508]. MPLS_FULL_HEADER packets are also sent to
Berger & Jeffords [Page 7]
Internet Draft draft-ietf-mpls-hdr-comp-00.txt July 2000
indicate a change in EXP field handling.
The compressor and decompressor need to agree on the number of MPLS
label stack entries that may be present before an IP header. The
compressor and decompressor SHOULD negotiate the maximum number
allowed. If no maximum number of MPLS headers is negotiated or
configured, a default of one (1) SHALL be used. Packets containing
more than the maximum number of MPLS headers MUST not be compressed.
3.2. COMPRESSED_MPLS Packet Format
The COMPRESSED_MPLS packet carries a compressed MPLS label stack and
all other headers uncompressed. It is used to cover the cases where
a full IP and TCP or UDP header must be sent.
The format of a COMPRESSED_MPLS packet is:
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+-------------------------------+
: EXP Compression Fields : (see Section 3.5)
+-------------------------------+
| Uncompressed IP packet |
: :
3.3. Baseline Operation
Under normal conditions the number of MPLS label stack entries and
the contents of each entry is expected to remain constant over the
life of a session. (Section 3.5 covers the case where the EXP field
is expected to change on a per packet basis.) Operation in this mode
is selected by the P-bit, for more details see section 3.4. In this
mode, all MPLS headers will be transmitted in MPLS_FULL_HEADER
packets and stored by the decompressor. Once the MPLS headers are
transmitted and stored by the decompressor, they no longer need to be
transmitted. This means that after a MPLS_FULL_HEADER packet is sent
for a particular session, the standard IP and IP/UDP/RTP compression
packet formats and associated processing may be used without any
modifications.
While the standard packet formats are used, the decompressor must of
course be extended to reconstructs the original MPLS headers for all
MPLS session. When reconstructing the headers of an MPLS/IP packet
Berger & Jeffords [Page 8]
Internet Draft draft-ietf-mpls-hdr-comp-00.txt July 2000
received in any compressed packet type, the decompressor MUST perform
the same context validation checks as described in Section 10.2 of
[RFC2507] and Section 3.3.5 of [RFC2508]. If the checks fail, a
corresponding CONTEXT_STATE packet MUST be sent. If the checks pass
the decompressor adds the MPLS headers associated with the CID.
There is one standard packet type that must be handled differently.
For sessions not associated with MPLS, the FULL_HEADER packet is used
to identify and reset the session context. When a session is
identified as using MPLS headers, via a MPLS_FULL_HEADER packet, the
FULL_HEADER packet must be handled differently. For MPLS sessions,
the FULL_HEADER packet is not used. If a FULL_HEADER packet is
received with a CID matching an MPLS session, the receiver must
assume that the CID is being reused for a new non-MPLS session and it
MUST reset all session context based on the received FULL_HEADER
packet.
When a CONTEXT_STATE packet is received for an MPLS session, a
MPLS_FULL_HEADER packet MUST be sent rather than a FULL_HEADER
packet. Note that per [RFC2508] and [RFC2507] generating a packet is
not always required in response to a received a CONTEXT_STATE packet.
3.4. Setting the P-bit
The P-bit is carried in MPLS_FULL_HEADER packets and controls whether
EXP bits are carried in compressed packets. When the EXP fields in
all present MPLS label stack entries are expected to remain constant
on a packet-by-packet basis, the P-bit SHOULD be set. Values used in
the MPLS EXP field typically depend on whether Differentiated
Services [DIFFSERV] is being supported. When Diff-Serv is not being
used, the EXP field will typically remain constant. When Diff-Serv
is being supported, the EXP field may change packet-by-packet for
some applications and remain constant for others. Because of these
different cases, it will generally be difficult to identify which
MPLS sessions will be regularly changing EXP fields and which will
not.
To support these cases, all new sessions SHOULD be initiated with the
P-bit set when possible. (As previously noted, the P-bit is not
carried in some exception cases.) When the first change in an EXP
field is seen by the compressor, it MUST send a new MPLS_FULL_HEADER
packet. At this point it may choose to not set the P-bit, or it may
choose to wait to see if EXP changes are frequent. If EXP changes
are observed to be frequent, the compressor SHOULD NOT set the P-bit.
Operation when the P-bit is not set is described in Section 3.5. A
compressor MAY be configured to never set the P-bit.
Berger & Jeffords [Page 9]
Internet Draft draft-ietf-mpls-hdr-comp-00.txt July 2000
3.5. The EXP Compression Field
When the P-bit is not present, or is not set in the session's most
recent associated MPLS_FULL_HEADER packet, the session is said to be
in "EXP mode". In this mode one or more EXP fields are expected to
change on as much as a per packet-by-packet basis. To support this
mode a new field, called the EXP Compression field, is defined. When
operating in EXP mode, at least one EXP Compression field is included
in all compressed packet types. Compressed packet types are the
types defined in [RFC2507], [RFC2508] and earlier in this document
and begin with "COMPRESSED_."
Each EXP Compression field references a single MPLS label stack entry
and provides the 3 bit EXP field to be used with that entry.
Multiple EXP Compression fields may be included when more than stack
entry is present. At most changes to 16 stack entries can be
supported.
Only changes in EXP fields are carried, and the receiver MUST store
the most recently received value. If no changes in EXP fields are
observed, one EXP Compression field MUST be included in the
compressed packet. In this case, the EXP Compression field SHOULD
carry the EXP bits from the topmost stack entry. Per [LABELS], the
top of the label stack appears earliest in the packet, and the bottom
appears latest.
The format of the EXP Compression field is:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| offset | L | EXP |
+---+---+---+---+---+---+---+---+
Offset indicates the count from the top of the stack to the
corresponding label stack entry. To reference a particular stack
entry, offset is incremented for each stack entry between the
link layer header and the desired stack entry, e.g., zero
indicates the top of the stack and two would indicate the third
stack entry.
The L-bit is set in the last EXP Compression field present in the
packet. A zero indicates that there is another EXP Compression
field immediately following this field.
EXP is copied from the corresponding label stack entry.
EXP Compression fields are carried as indicated in Section 3.2 and
prior to the "RANDOM" fields defined in [RFC2507] and [RFC2508] in
Berger & Jeffords [Page 10]
Internet Draft draft-ietf-mpls-hdr-comp-00.txt July 2000
other compressed packets. Two example modified packet formats are:
COMPRESSED_TCP format [RFC2507] for MPLS EXP mode session
+-+-+-+-+-+-+-+-+
| CID |
+-+-+-+-+-+-+-+-+
|R O I P S A W U|
+-+-+-+-+-+-+-+-+
| |
+ TCP Checksum +
| |
+-+-+-+-+-+-+-+-+
- - - - - - - -
| EXP Compression fields (implied)
- - - - - - - -
| RANDOM fields, if any (see section 7) (implied)
- - - - - - - -
| R-octet | (if R=1)
- - - - - - - -
| Urgent Pointer Value (if U=1)
- - - - - - - -
| Window Delta (if W=1)
- - - - - - - -
| Acknowledgment Number Delta (if A=1)
- - - - - - - -
| Sequence Number Delta (if S=1)
- - - - - - - -
| IPv4 Identification Delta (if I=1)
- - - - - - - -
| Options (if O=1)
- - - - - - - -
Berger & Jeffords [Page 11]
Internet Draft draft-ietf-mpls-hdr-comp-00.txt July 2000
COMPRESSED_UDP packet format [RFC2508] for MPLS EXP mode session
0 1 2 3 4 5 6 7
+...............................+
: msb of session context ID : (if 16-bit CID)
+-------------------------------+
| lsb of session context ID |
+---+---+---+---+---+---+---+---+
| 0 | 0 | 0 | I | link sequence |
+---+---+---+---+---+---+---+---+
: :
+ UDP checksum + (if nonzero in context)
: :
+---+---+---+---+---+---+---+---+
| offset | L | EXP | EXP Compression fields
+---+---+---+---+---+---+---+---+
: :
+ "RANDOM" fields + (if encapsulated)
: :
+...............................+
: delta IPv4 ID : (if I = 1)
+-------------------------------+
| UDP data |
: (uncompressed RTP header) :
Note that there may be more than one EXP Compression field per
packet.
3.6. Compatibility
MPLS and standard IP and IP/UDP/RTP compression can be performed on
the same link. MPLS and IP sessions are distinguished via the use of
MPLS_FULL_HEADER or FULL_HEADER packets. Once a session context is
initialized, the CID implies whether MPLS headers are compressed. It
is important to note that there is no separate MPLS session CID
space. MPLS sessions share the TCP and non-TCP CID spaces.
MPLS/IP/TCP sessions share the TCP CID space. Other sessions,
including MPLS/IP/UDP/RTP sessions, share the non-TCP space.
It is also necessary for a compressor to know when a decompressor
supports MPLS/IP compression. This information can be configured or
negotiated. The default behavior is to assume that the decompressor
does not support MPLS/IP compression.
Finally, the compressor needs to know the maximum number of MPLS
stack entries the decompressor can process. This too can be
configured or negotiated. The previously mentioned default is to
Berger & Jeffords [Page 12]
Internet Draft draft-ietf-mpls-hdr-comp-00.txt July 2000
assume only one entry, i.e., one MPLS header, is supported.
4. Negotiating MPLS/IP Compression
The use of MPLS/IP compression over a particular link is a function
of the link-layer protocol. As in [RFC2508], it is expected that
such negotiation will be defined separately for PPP, for example.
The following additional items SHOULD be negotiated:
o If MPLS/IP compression is supported
o The maximum stack depth supported
5. Security Considerations
No new security issues are raised by this document. Please see
[RFC2507] and [RFC2508] for a detailed discussion of existing
considerations associated with header compression.
6. Open/Potential Issues
This document doesn't support the CRTP enhancements proposed in
draft-koren-avt-crtp-enhance-01.txt. It's not clear if this is an
issue. The progress of the enhancements in the AVT working group
should be tracked to see if it becomes an issue.
7. References
[DIFFSERV] Faucheur, Wu, Davie, Davari, Vaananen, Krishnan,
Cheval, "MPLS Support of Differentiated Services",
draft-ietf-mpls-diff-ext-05.txt, June, 2000.
[LABELS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, Conta,
"MPLS Label Stack Encoding",
draft-ietf-mpls-label-encaps-07.txt, September 1999.
[RFC1144] Jacobson, V., "TCP/IP Compression for Low-Speed Serial
Links", RFC 1144, February 1990.
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC2508] Casner, S., Jacobson, V., "Compressing IP/UDP/RTP Headers
for Low-Speed Serial Link", RFC 2508, February 1999.
Berger & Jeffords [Page 13]
Internet Draft draft-ietf-mpls-hdr-comp-00.txt July 2000
[STD51] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
8. Authors' Address
Lou Berger Jason Jeffords
LabN Consulting, LLC Integral Access Inc.
Voice: +1 301 468 9228 6 Omni Way
Email: lberger@labn.net Chelmsford, MA 01824
Voice: +1 978 256 8833
Email: jjeffords@integralaccess.com
Berger & Jeffords [Page 14]
Html markup produced by rfcmarkup 1.122, available from
https://tools.ietf.org/tools/rfcmarkup/