A Framework for Transmission of IP Datagrams over MPEG-2 Networks
RFC 4259
| Document | Type | RFC - Informational (December 2005) | |
|---|---|---|---|
| Authors | Gorry Fairhurst , Marie-Jose Montpetit , Bernhard Collini-Nocker , Hilmar Linder , Horst D. Clausen | ||
| Last updated | 2018-12-20 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | Margaret Cullen | |
| Send notices to | (None) |
RFC 4259
Network Working Group M.-J. Montpetit
Request for Comments: 4259 Motorola Connected Home Solutions
Category: Informational G. Fairhurst
University of Aberdeen
H. Clausen
TIC Systems
B. Collini-Nocker
H. Linder
University of Salzburg
November 2005
A Framework for Transmission of IP Datagrams over MPEG-2 Networks
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
This document describes an architecture for the transport of IP
Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has
been widely accepted not only for providing digital TV services but
also as a subnetwork technology for building IP networks. Examples
of systems using MPEG-2 include the Digital Video Broadcast (DVB) and
Advanced Television Systems Committee (ATSC) Standards for Digital
Television.
The document identifies the need for a set of Internet standards
defining the interface between the MPEG-2 Transport Stream and an IP
subnetwork. It suggests a new encapsulation method for IP datagrams
and proposes protocols to perform IPv6/IPv4 address resolution, to
associate IP packets with the properties of the Logical Channels
provided by an MPEG-2 TS.
Montpetit, et al. Informational [Page 1]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
Table of Contents
1. Introduction ....................................................3
1.1. Salient Features of the Architecture .......................4
2. Conventions Used in This Document ...............................4
3. Architecture ....................................................8
3.1. MPEG-2 Transmission Networks ...............................8
3.2. TS Logical Channels .......................................10
3.3. Multiplexing and Re-Multiplexing ..........................12
3.4. IP Datagram Transmission ..................................13
3.5. Motivation ................................................14
4. Encapsulation Protocol Requirements ............................16
4.1. Payload Unit Delimitation .................................17
4.2. Length Indicator ..........................................18
4.3. Next Level Protocol Type ..................................19
4.4. L2 Subnet Addressing ......................................19
4.5. Integrity Check ...........................................21
4.6. Identification of Scope. ..................................21
4.7. Extension Headers .........................................21
4.8. Summary of Requirements for Encapsulation .................22
5. Address Resolution Functions ...................................22
5.1. Address Resolution for MPEG-2 .............................23
5.2. Scenarios for MPEG AR .....................................25
5.2.1. Table-Based AR over MPEG-2 .........................25
5.2.2. Table-Based AR over IP .............................26
5.2.3. Query/Response AR over IP ..........................26
5.3. Unicast Address Scoping ...................................26
5.4. AR Authentication .........................................27
5.5. Requirements for Unicast AR over MPEG-2 ...................28
6. Multicast Support ..............................................28
6.1. Multicast AR Functions ....................................29
6.2. Multicast Address Scoping .................................30
6.3. Requirements for Multicast over MPEG-2 ....................31
7. Summary ........................................................31
8. Security Considerations ........................................32
8.1. Link Encryption ...........................................33
9. IANA Considerations ............................................34
10. Acknowledgements ..............................................34
11. References ....................................................34
11.1. Normative References .....................................34
11.2. Informative References ...................................34
Appendix A ........................................................39
Montpetit, et al. Informational [Page 2]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
1. Introduction
This document identifies requirements and an architecture for the
transport of IP Datagrams over ISO MPEG-2 Transport Streams
[ISO-MPEG]. The prime focus is the efficient and flexible delivery
of IP services over those subnetworks that use the MPEG-2 Transport
Stream (TS).
The architecture is designed to be compatible with services based on
MPEG-2, for example the Digital Video Broadcast (DVB) architecture,
the Advanced Television Systems Committee (ATSC) system [ATSC,
ATSC-G], and other similar MPEG-2-based transmission systems. Such
systems typically provide unidirectional (simplex) physical and link
layer standards, and have been defined for a wide range of physical
media (e.g., Terrestrial TV [ETSI-DVBT, ATSC-PSIP-TC], Satellite TV
[ETSI-DVBS, ETSI-DVBS2, ATSC-S], Cable Transmission [ETSI-DVBC,
ATSC-PSIP-TC, OPEN-CABLE], and data transmission over MPEG-2
[ETSI-MHP].
+-+-+-+-+------+------------+---+--+--+---------+
|T|V|A|O| O | | O |S |O | |
|e|i|u|t| t | | t |I |t | |
|l|d|d|h| h | IP | h | |h | Other |
|e|e|i|e| e | | e |T |e |protocols|
|t|o|o|r| r | | r |a |r | native |
|e| | | | | | |b | | over |
|x| | | | | +---+----+-+ |l | |MPEG-2 TS|
|t| | | | | | | MPE | |e | | |
| | | | | +--+---+ +------+ | | | |
| | | | | | AAL5 |ULE|Priv. | | | | |
+-+-+-+-+---+------+ | +-+--+--+ |
| PES | ATM | |Sect. |Section| |
+-------+----------+---+------+-------+---------+
| MPEG-2 TS |
+---------+-------+----------------+------------+
|Satellite| Cable | Terrestrial TV | Other PHY |
+---------+-------+----------------+------------+
Figure 1: Overview of the MPEG-2 protocol stack
Although many MPEG-2 systems carry a mixture of data types, MPEG-2
components may be, and are, also used to build IP-only networks.
Standard system components offer advantages of improved
interoperability and larger deployment. However, some MPEG-2
networks do not implement all parts of a DVB / ATSC system, and may,
for instance, support minimal, or no, signalling of Service
Information (SI) tables.
Montpetit, et al. Informational [Page 3]
RFC 4259 IP Transport over MPEG-2 Networks November 2005This 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Tree diagram . . . . . . . . . . . . . . . . . . . . . . 2
2. Design of the Data Model . . . . . . . . . . . . . . . . . . 3
2.1. ISIS Configuration . . . . . . . . . . . . . . . . . . . 8
2.2. Multitopology Parameters . . . . . . . . . . . . . . . . 9
2.3. Per-Level Parameters . . . . . . . . . . . . . . . . . . 10
2.4. Per-Interface Parameters . . . . . . . . . . . . . . . . 10
2.5. Operational State . . . . . . . . . . . . . . . . . . . . 11
3. RPC Operations . . . . . . . . . . . . . . . . . . . . . . . 15
4. Notifications . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Interaction with Other YANG Modules . . . . . . . . . . . . . 20
6. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 82
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 83
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 83
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83
11. Normative References . . . . . . . . . . . . . . . . . . . . 83
Appendix A. Example: NETCONF <get> Reply . . . . . . . . . . . . 84
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
1. Introduction
This document defines a YANG data model for ISIS routing protocol.
The data model covers configuration of an ISIS routing protocol
instance as well as operational states.
1.1. Tree diagram
A simplified graphical representation of the data model is presented
in Section 2.
The meaning of the symbols in these diagrams is as follows:
o Brackets "[" and "]" enclose list keys.
Litkowski, et al. Expires April 27, 2015 [Page 2]
Internet-Draft isis-cfg October 2014
o Curly braces "{" and "}" contain names of optional features that
make the corresponding node conditional.
o Abbreviations before data node names: "rw" means configuration
(read-write), and "ro" state data (read-only).
o Symbols after data node names: "?" means an optional node and "*"
denotes a "list" or "leaf-list".
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
2. Design of the Data Model
The ISIS YANG module is divided in two main containers "isis" that
are augmenting the "routing-protocol" lists in ietf-routing module
with specific ISIS parameters.
One container contains the writable parameters, while the other
contains the operational states.
The figure below describe the overall structure of the isis YANG
module:
module: ietf-isis
augment /rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route:
+--ro metric? uint32
+--ro tag* uint64
+--ro route-type? enumeration
augment /rt:active-route/rt:output/rt:route:
+--ro metric? uint32
+--ro tag* uint64
+--ro route-type? enumeration
augment /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol:
+--rw isis
+--rw instance* [routing-instance]
+--rw routing-instance rt:routing-instance-ref
+--rw level-type? level
+--rw system-id? system-id
+--rw maximum-area-addresses? uint8 {maximum-area-addresses}?
+--rw area-address* area-address
+--rw mpls-te
| ...
+--rw reference-bandwidth? uint32 {reference-bandwidth}?
+--rw lsp-mtu? uint16
Litkowski, et al. Expires April 27, 2015 [Page 3]
Internet-Draft isis-cfg October 2014
+--rw lsp-lifetime? uint16
+--rw lsp-refresh? uint16 {lsp-refresh}?
+--rw graceful-restart {graceful-restart}?
| ...
+--rw authentication* [level]
| ...
+--rw metric-type* [level]
| ...
+--rw preference* [level]
| ...
+--rw default-metric* [level]
| ...
+--rw af* [af] {nlpid-control}?
| ...
+--rw topologies* [name] {multi-topology}?
| ...
+--rw overload* [level]
| ...
+--rw overload-max-metric* [level] {overload-max-metric}?
| ...
+--rw interfaces
...
augment /rt:routing-state/rt:routing-instance/rt:routing-protocols/rt:routing-protocol:
+--ro isis
+--ro system-counters
| +--ro level* [level]
| ...
+--ro interface-counters
| +--ro interface* [interface]
| ...
+--ro packet-counters
| +--ro level* [level]
| ...
+--ro interfaces
| +--ro interfaces* [interface]
| ...
+--ro adjacencies
| +--ro adjacency*
| ...
+--ro spf-log
| +--ro event* [id]
| ...
+--ro lsp-log
| +--ro event* [id]
| ...
+--ro database
| +--ro level-db* [level]
| ...
Litkowski, et al. Expires April 27, 2015 [Page 4]
Internet-Draft isis-cfg October 2014
+--ro hostnames
+--ro hostname* [system-id]
...
rpcs:
+---x clear-adjacency
| +--ro input
| +--ro routing-instance-name rt:routing-instance-state-ref
| +--ro routing-protocol-instance-name instance-state-ref
| +--ro level? level
| +--ro interface? string
+---x clear-database
+--ro input
+--ro routing-instance-name rt:routing-instance-state-ref
+--ro routing-protocol-instance-name instance-state-ref
+--ro level? level
notifications:
+---n database-overload
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro overload? enumeration
+---n lsp-too-large
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro pdu-size? uint32
| +--ro lsp-id? lsp-id
+---n corrupted-lsp-detected
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro lsp-id? lsp-id
+---n attempt-to-exceed-max-sequence
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro lsp-id? lsp-id
+---n id-len-mismatch
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro pdu-field-len? uint8
| +--ro raw-pdu? binary
+---n max-area-addresses-mismatch
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
Litkowski, et al. Expires April 27, 2015 [Page 5]
Internet-Draft isis-cfg October 2014
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro max-area-addresses? uint8
| +--ro raw-pdu? binary
+---n own-lsp-purge
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro lsp-id? lsp-id
+---n sequence-number-skipped
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro lsp-id? lsp-id
+---n authentication-type-failure
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro raw-pdu? binary
+---n authentication-failure
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro raw-pdu? binary
+---n version-skew
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro protocol-version? uint8
| +--ro raw-pdu? binary
+---n area-mismatch
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro raw-pdu? binary
+---n rejected-adjacency
Litkowski, et al. Expires April 27, 2015 [Page 6]
Internet-Draft isis-cfg October 2014
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro raw-pdu? binary
| +--ro reason? string
+---n protocols-supported-mismatch
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro raw-pdu? binary
| +--ro protocols* uint8
+---n lsp-error-detected
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro lsp-id? lsp-id
| +--ro raw-pdu? binary
| +--ro error-offset? uint32
| +--ro tlv-type? uint8
+---n adjacency-change
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro neighbor? string
| +--ro neighbor-system-id? system-id
| +--ro level? level
| +--ro state? enumeration
| +--ro reason? string
+---n lsp-received
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro lsp-id? lsp-id
| +--ro sequence? uint32
| +--ro received-timestamp? yang:timestamp
| +--ro neighbor-system-id? system-id
+---n lsp-generation
+--ro instance-name? string
Litkowski, et al. Expires April 27, 2015 [Page 7]
Internet-Draft isis-cfg October 2014
+--ro instance-level? level
+--ro lsp-id? lsp-id
+--ro sequence? uint32
+--ro send-timestamp? yang:timestamp
2.1. ISIS Configuration
The ISIS configuration currently supports both VRF-centric and
protocol-centric configuration. This may be changed in future. In a
protocol-centric configuration, the isis configuration is applied
within the standard-routing-instance and the instance list helps to
reference the routing-instance where ISIS is activated. In a VRF-
centric configuration, the isis configuration is applied directly
within the appropriate routing-instance where ISIS is activated. In
this case, the instance list will contain a single element.
The ISIS configuration container is divided in:
o Global parameters.
o Per interface configuration (see Section 2.4).
It would to up to extension modules to augment this model to support
vendor specific parameters.
augment /rt:routing/rt:routing-instance/rt:routing-protocols/rt:routing-protocol:
+--rw isis
+--rw instance* [routing-instance]
+--rw routing-instance rt:routing-instance-ref
+--rw level-type? level
+--rw system-id? system-id
+--rw maximum-area-addresses? uint8 {maximum-area-addresses}?
+--rw area-address* area-address
+--rw mpls-te
| +--rw ipv4-router-id? inet:ipv4-address {ipv4-router-id}?
| +--rw ipv6-router-id? inet:ipv6-address {ipv6-router-id}?
+--rw reference-bandwidth? uint32 {reference-bandwidth}?
+--rw lsp-mtu? uint16
+--rw lsp-lifetime? uint16
+--rw lsp-refresh? uint16 {lsp-refresh}?
+--rw graceful-restart {graceful-restart}?
| +--rw enabled? boolean
+--rw authentication* [level]
Litkowski, et al. Expires April 27, 2015 [Page 8]
Internet-Draft isis-cfg October 2014
| +--rw key? string
| +--rw type? authentication-type
| +--rw level level
+--rw metric-type* [level]
| +--rw value? enumeration
| +--rw level level
+--rw preference* [level]
| +--rw (granularity)?
| | +--:(detail)
| | | +--rw internal? uint8
| | | +--rw external? uint8
| | +--:(coarse)
| | +--rw default? uint8
| +--rw level level
+--rw default-metric* [level]
| +--rw value? wide-metric
| +--rw level level
+--rw af* [af] {nlpid-control}?
| +--rw af string
| +--rw enabled? boolean
+--rw topologies* [name] {multi-topology}?
| +--rw enabled? boolean
| +--rw name rt:rib-ref
| +--rw default-metric* [level]
| +--rw value? wide-metric
| +--rw level level
+--rw overload* [level]
| +--rw status? boolean
| +--rw timeout? uint16
| +--rw level level
+--rw overload-max-metric* [level] {overload-max-metric}?
| +--rw status? boolean
| +--rw timeout? uint16
| +--rw level level
+--rw interfaces
+--rw interface* [name]
...
2.2. Multitopology Parameters
The topologies list is used to enable support of MT extensions for
specific address families.
Each topology should refer to an existing RIB.
Litkowski, et al. Expires April 27, 2015 [Page 9]
Internet-Draft isis-cfg October 2014
2.3. Per-Level Parameters
Some parameters support per level configuration. In this case, the
parameter is built as a list, so different values could be used for
each level. The "level-all" permits to apply a value to both levels.
+--rw priority* [level]
| +--rw value? uint8
| +--rw level level
Example :
<priority>
<value>100</value>
<level>level-1</level>
</priority>
<priority>
<value>200</value>
<level>level-2</level>
</priority>
2.4. Per-Interface Parameters
The per-interface section of the ISIS instance describes the
interface specific parameters.
The interface is referenced using a string. It would be up to the
server device to check if the interface exists or not. Using a
string permits to support some specific implementations that use the
"interface all" stanza to apply a configuration to all interfaces.
Each interface has interface-specific parameters that may have a
different value per level as described in previous section. An
interface-specific parameter always override an ISIS global parameter
.
Some parameters like BFD and hello-padding are defined as containers
to permit easy extension by vendor specific modules.
Litkowski, et al. Expires April 27, 2015 [Page 10]
Internet-Draft isis-cfg October 2014
+--rw interfaces
+--rw interface* [name]
+--rw name string
+--rw level-type? level
+--rw lsp-pacing-interval? uint16
+--rw lsp-retransmit-interval? uint16
+--rw passive? boolean
+--rw csnp-interval? uint16
+--rw hello-padding
| +--rw enabled? boolean
+--rw mesh-group-enabled? mesh-group-state
+--rw mesh-group? uint8
+--rw interface-type? interface-type
+--rw enabled? boolean
+--rw tag* uint32 {prefix-tag}?
+--rw tag64* uint64 {prefix-tag64}?
+--rw hello-authentication* [level]
| +--rw type? authentication-type
| +--rw key? string
| +--rw level level
+--rw hello-interval* [level]
| +--rw value? uint16
| +--rw level level
+--rw hello-multiplier* [level]
| +--rw value? uint16
| +--rw level level
+--rw priority* [level]
| +--rw value? uint8
| +--rw level level
+--rw metric* [level]
| +--rw value? wide-metric
| +--rw level level
+--rw af* [af]
| +--rw af string
| +--rw bfd {bfd}?
| ...
+--rw topologies* [name]
+--rw name rt:rib-ref
+--rw metric* [level]
...
2.5. Operational State
"isis" container provides operational states for ISIS. This
container is divided in multiple components:
o system-counters : provides statistical informations about the
global system.
Litkowski, et al. Expires April 27, 2015 [Page 11]
Internet-Draft isis-cfg October 2014
o interface-counters : provides statistical informations for each
interface.
o packet-counters : provides statistical informations for each type
of PDU.
o interface : provides configuration state information for each
interface.
o adjacencies: provides state information about current ISIS
adjacencies.
o spf-log: provides information about SPF events on the node.
o lsp-log: provides information about LSP events on the node
(reception of an LSP or modification of local LSP).
o database: provides details on current LSDB.
o hostnames: provides information about system-id to hostname
mappings.
augment /rt:routing-state/rt:routing-instance/rt:routing-protocols/rt:routing-protocol:
+--ro isis
+--ro system-counters
| +--ro level* [level]
| +--ro level level-number
| +--ro corrupted-lsps? uint32
| +--ro authentication-type-fails? uint32
| +--ro authentication-fails? uint32
| +--ro database-overload? uint32
| +--ro own-lsp-purge? uint32
| +--ro manual-address-drop-from-area? uint32
| +--ro max-sequence? uint32
| +--ro sequence-number-skipped? uint32
| +--ro id-len-mismatch? uint32
| +--ro partition-changes? uint32
| +--ro lsp-errors? uint32
| +--ro spf-runs? uint32
+--ro interface-counters
| +--ro interface* [interface]
| +--ro interface string
| +--ro adjacency-changes? uint32
| +--ro adjacency-number? uint32
| +--ro init-fails? uint32
| +--ro adjacency-rejects? uint32
| +--ro id-len-mismatch? uint32
| +--ro max-area-addresses-mismatch? uint32
Litkowski, et al. Expires April 27, 2015 [Page 12]
Internet-Draft isis-cfg October 2014
| +--ro authentication-type-fails? uint32
| +--ro authentication-fails? uint32
| +--ro lan-dis-changes? uint32
+--ro packet-counters
| +--ro level* [level]
| +--ro level level-number
| +--ro iih
| | +--ro in? uint32
| | +--ro out? uint32
| +--ro ish
| | +--ro in? uint32
| | +--ro out? uint32
| +--ro esh
| | +--ro in? uint32
| | +--ro out? uint32
| +--ro lsp
| | +--ro in? uint32
| | +--ro out? uint32
| +--ro psnp
| | +--ro in? uint32
| | +--ro out? uint32
| +--ro csnp
| | +--ro in? uint32
| | +--ro out? uint32
| +--ro unknown
| +--ro in? uint32
| +--ro out? uint32
+--ro interfaces
| +--ro interfaces* [interface]
| +--ro interface string
| +--ro circuit-id? circuit-id
| +--ro admin-state? admin-state
| +--ro oper-state? oper-state
| +--ro interface-type? interface-type
| +--ro level? level
| +--ro passive? empty
| +--ro three-way-handshake? empty
+--ro adjacencies
| +--ro adjacency*
| +--ro interface? string
| +--ro level? level
| +--ro neighbor-sysid? system-id
| +--ro neighbor-extended-circuit-id? extended-circuit-id
| +--ro neighbor-snpa? snpa
| +--ro neighbor-level? level
| +--ro hold-timer? uint16
| +--ro neighbor-priority? uint8
| +--ro lastuptime? yang:timestamp
Litkowski, et al. Expires April 27, 2015 [Page 13]
Internet-Draft isis-cfg October 2014
| +--ro state? enumeration
+--ro spf-log
| +--ro event* [id]
| +--ro id uint32
| +--ro spf-type? enumeration
| +--ro level? level-number
| +--ro spf-delay? uint32
| +--ro schedule-timestamp? yang:timestamp
| +--ro start-timestamp? yang:timestamp
| +--ro end-timestamp? yang:timestamp
| +--ro trigger-lsp* [lsp]
| +--ro lsp lsp-id
| +--ro sequence? uint32
+--ro lsp-log
| +--ro event* [id]
| +--ro id uint32
| +--ro level? level-number
| +--ro lsp
| | +--ro lsp? lsp-id
| | +--ro sequence? uint32
| +--ro received-timestamp? yang:timestamp
+--ro database
| +--ro level-db* [level]
| +--ro level level-number
| +--ro lsp* [lsp-id]
| +--ro lsp-id lsp-id
| +--ro checksum? uint16
| +--ro remaining-lifetime? uint16
| +--ro sequence? uint32
| +--ro attributes? bits
| +--ro is-neighbor
| | +--ro neighbor* [neighbor-id]
| | ...
| +--ro authentication
| | +--ro authentication-type? authentication-type
| | +--ro authentication-key? string
| +--ro extended-is-neighbor
| | +--ro neighbor* [neighbor-id]
| | ...
| +--ro ipv4-internal-reachability
| | +--ro prefixes* [ip-prefix]
| | ...
| +--ro protocol-supported* uint8
| +--ro ipv4-external-reachability
| | +--ro prefixes* [ip-prefix]
| | ...
| +--ro ipv4-addresses* inet:ipv4-address
| +--ro ipv4-te-routerid? inet:ipv4-address
Litkowski, et al. Expires April 27, 2015 [Page 14]
Internet-Draft isis-cfg October 2014
| +--ro extended-ipv4-reachability
| | +--ro prefixes* [ip-prefix]
| | ...
| +--ro dynamic-hostname? string
| +--ro ipv6-te-routerid? inet:ipv6-address
| +--ro mt-is-neighbor
| | +--ro neighbor* [neighbor-id]
| | ...
| +--ro mt-entries
| | +--ro topology* [MT-ID]
| | ...
| +--ro ipv6-addresses* inet:ipv6-address
| +--ro mt-extended-ipv4-reachability
| | +--ro prefixes* [ip-prefix]
| | ...
| +--ro mt-ipv6-reachability
| | +--ro prefixes* [ip-prefix]
| | ...
| +--ro ipv6-reachability
| | +--ro prefixes* [ip-prefix]
| | ...
| +--ro router-capabilities
| +--ro binary? binary
+--ro hostnames
+--ro hostname* [system-id]
+--ro system-id system-id
+--ro hostname? string
3. RPC Operations
The "ietf-isis" module defines two RPC operations:
o clear-isis-database: reset the content of a particular ISIS
database and restart database synchronization with the neighbors.
o clear-isis-adjacency: restart a particular set of ISIS
adjacencies.
Litkowski, et al. Expires April 27, 2015 [Page 15]
Internet-Draft isis-cfg October 2014
rpcs:
+---x clear-adjacency
| +--ro input
| +--ro routing-instance-name rt:routing-instance-state-ref
| +--ro routing-protocol-instance-name instance-state-ref
| +--ro level? level
| +--ro interface? string
+---x clear-database
+--ro input
+--ro routing-instance-name rt:routing-instance-state-ref
+--ro routing-protocol-instance-name instance-state-ref
+--ro level? level
4. Notifications
The "ietf-isis" module introduces some notifications :
database-overload : raised when overload condition is changed.
lsp-too-large : raised when the system tries to propagate a too
large PDU.
corrupted-lsp-detected : raised when the system find that an LSP
that was stored in memory has become corrupted.
attempt-to-exceed-max-sequence : This notification is sent when
the system wraps the 32-bit sequence counter of an LSP.
id-len-mismatch : This notification is sent when we receive a PDU
with a different value for the System ID length.
max-area-addresses-mismatch : This notification is sent when we
receive a PDU with a different value for the Maximum Area
Addresses.
own-lsp-purge : This notification is sent when the system receives
a PDU with its own system ID and zero age.
sequence-number-skipped : This notification is sent when the
system receives a PDU with its own system ID and different
contents. The system has to reissue the LSP with a higher
sequence number.
authentication-type-failure : This notification is sent when the
system receives a PDU with the wrong authentication type field.
authentication-failure : This notification is sent when the system
receives a PDU with the wrong authentication information.
Litkowski, et al. Expires April 27, 2015 [Page 16]
Internet-Draft isis-cfg October 2014
version-skew : This notification is sent when the system receives
a PDU with a different protocol version number.
area-mismatch : This notification is sent when the system receives
a Hello PDU from an IS that does not share any area address.
rejected-adjacency : This notification is sent when the system
receives a Hello PDU from an IS but does not establish an
adjacency for some reason.
protocols-supported-mismatch : This notification is sent when the
system receives a non pseudonode LSP that has no matching protocol
supported.
lsp-error-detected : This notification is sent when the system
receives a LSP with a parse error.
adjacency-change : This notification is sent when an ISIS
adjacency moves to Up state or to Down state.
lsp-received : This notification is sent when a LSP is received.
lsp-generation : This notification is sent when a LSP is
regenerated.
notifications:
+---n database-overload
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro overload? enumeration
+---n lsp-too-large
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro pdu-size? uint32
| +--ro lsp-id? lsp-id
+---n corrupted-lsp-detected
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro lsp-id? lsp-id
+---n attempt-to-exceed-max-sequence
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro lsp-id? lsp-id
+---n id-len-mismatch
| +--ro instance-name? string
Litkowski, et al. Expires April 27, 2015 [Page 17]
Internet-Draft isis-cfg October 2014
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro pdu-field-len? uint8
| +--ro raw-pdu? binary
+---n max-area-addresses-mismatch
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro max-area-addresses? uint8
| +--ro raw-pdu? binary
+---n own-lsp-purge
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro lsp-id? lsp-id
+---n sequence-number-skipped
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro lsp-id? lsp-id
+---n authentication-type-failure
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro raw-pdu? binary
+---n authentication-failure
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro raw-pdu? binary
+---n version-skew
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
Litkowski, et al. Expires April 27, 2015 [Page 18]
Internet-Draft isis-cfg October 2014
| +--ro protocol-version? uint8
| +--ro raw-pdu? binary
+---n area-mismatch
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro raw-pdu? binary
+---n rejected-adjacency
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro raw-pdu? binary
| +--ro reason? string
+---n protocols-supported-mismatch
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro raw-pdu? binary
| +--ro protocols* uint8
+---n lsp-error-detected
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro lsp-id? lsp-id
| +--ro raw-pdu? binary
| +--ro error-offset? uint32
| +--ro tlv-type? uint8
+---n adjacency-change
| +--ro instance-name? string
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro neighbor? string
| +--ro neighbor-system-id? system-id
| +--ro level? level
| +--ro state? enumeration
| +--ro reason? string
+---n lsp-received
| +--ro instance-name? string
Litkowski, et al. Expires April 27, 2015 [Page 19]
Internet-Draft isis-cfg October 2014
1.1. Salient Features of the Architecture
The architecture defined in this document describes a set of
protocols that support transmission of IP packets over the MPEG-2 TS.
Key characteristics of these networks are that they may provide
link-level broadcast capability, and that many supported applications
require access to a very large number of subnetwork nodes.
Some, or all, of these protocols may also be applicable to other
subnetworks, e.g., other MPEG-2 transmission networks, regenerative
satellite links [ETSI-BSM], and some types of broadcast wireless
links. The key goals of the architecture are to reduce complexity
when using the system, while improving performance, increasing
flexibility for IP services, and providing opportunities for better
integration with IP services.
Since a majority of MPEG-2 transmission networks are bandwidth-
limited, encapsulation protocols must therefore add minimal overhead
to ensure good link efficiency while providing adequate network
services. They also need to be simple to minimize processing, robust
to errors and security threats, and extensible to a wide range of
services.
In MPEG-2 systems, TS Logical Channels, are identified by their PID
and provide multiplexing, addressing, and error reporting. The TS
Logical Channel may also be used to provide Quality of Service (QoS).
Mapping functions are required to relate TS Logical Channels to IP
addresses, to map TS Logical Channels to IP-level QoS, and to
associate IP flows with specific subnetwork capabilities. An
important feature of the architecture is that these functions may be
provided in a dynamic way, allowing transparent integration with
other IP-layer protocols. Collectively, these will form an MPEG-2 TS
Address Resolution (AR) protocol suite [IPDVB-AR].
2. Conventions Used in This Document
Adaptation Field: An optional variable-length extension field of the
fixed-length TS Packet header, intended to convey clock references
and timing and synchronization information as well as stuffing over
an MPEG-2 Multiplex [ISO-MPEG].
ATSC: Advanced Television Systems Committee [ATSC]. A framework and
a set of associated standards for the transmission of video, audio,
and data using the ISO MPEG-2 standard [ISO-MPEG].
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A
format for transmission of data and control information defined by
the ISO MPEG-2 standard that is carried in an MPEG-2 Private Section.
Montpetit, et al. Informational [Page 4]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
DVB: Digital Video Broadcast [ETSI-DVBC, ETSI-DVBRCS, ETSI-DVBS]. A
framework and set of associated standards published by the European
Telecommunications Standards Institute (ETSI) for the transmission of
video, audio, and data, using the ISO MPEG-2 Standard [ISO-MPEG].
Encapsulator: A network device that receives PDUs and formats these
into Payload Units (known here as SNDUs) for output as a stream of TS
Packets.
Forward Direction: The dominant direction of data transfer over a
network path. Data transfer in the forward direction is called
"forward transfer". Packets travelling in the forward direction
follow the forward path through the IP network.
MAC: Medium Access and Control. The link layer header of the
Ethernet IEEE 802 standard of protocols, consisting of a 6B
destination address, 6B source address, and 2B type field (see also
NPA).
MPE: Multiprotocol Encapsulation [ETSI-DAT, ATSC-DAT, ATSC-DATG]. A
scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each
Section is sent in a series of TS Packets using a single TS Logical
Channel.
MPEG-2: A set of standards specified by the Motion Picture Experts
Group (MPEG), and standardized by the International Standards
Organisation (ISO) [ISO-MPEG].
NPA: Network Point of Attachment. Addresses primarily used for
station (Receiver) identification within a local network (e.g., IEEE
MAC address). An address may identify individual Receivers or groups
of Receivers.
PAT: Program Association Table [ISO-MPEG]. An MPEG-2 PSI control
table that associates program numbers with the PID value used to send
the corresponding PMT. The PAT is sent using the well-known PID
value of zero.
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames,
IPv4 or IPv6 datagrams, and other network packets.
PES: Packetized Elementary Stream [ISO-MPEG]. A format of MPEG-2 TS
packet payload usually used for video or audio information.
PID: Packet Identifier [ISO-MPEG]. A 13 bit field carried in the
header of TS Packets. This is used to identify the TS Logical
Channel to which a TS Packet belongs [ISO-MPEG]. The TS Packets
forming the parts of a Table Section, PES, or other Payload Unit must
Montpetit, et al. Informational [Page 5]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
all carry the same PID value. The all 1s PID value indicates a Null
TS Packet introduced to maintain a constant bit rate of a TS
Multiplex. There is no required relationship between the PID values
used for TS Logical Channels transmitted using different TS
Multiplexes.
PMT: Program Map Table. An MPEG-2 PSI control table that associates
the PID values used by the set of TS Logical Channels/Streams that
comprise a program [ISO-MPEG]. The PID value which is used to send
the PMT for a specific program is defined by an entry in the PAT.
PP: Payload Pointer [ISO-MPEG]. An optional one byte pointer that
directly follows the TS Packet header. It contains the number of
bytes between the end of the TS Packet header and the start of a
Payload Unit. The presence of the Payload Pointer is indicated by
the value of the PUSI bit in the TS Packet header. The Payload
Pointer is present in DSM-CC and Table Sections; it is not present in
TS Logical Channels that use the PES-format.
Private Section: A syntactic structure constructed in accordance with
Table 2-30 of [ISO-MPEG]. The structure may be used to identify
private information (i.e., not defined by [ISO-MPEG]) relating to one
or more elementary streams, or a specific MPEG-2 program, or the
entire TS. Other Standards bodies (e.g., ETSI, ATSC) have defined
sets of table structures using the private_section structure. A
Private Section is transmitted as a sequence of TS Packets using a TS
Logical Channel. A TS Logical Channel may carry sections from more
than one set of tables.
PSI: Program Specific Information [ISO-MPEG]. PSI is used to convey
information about services carried in a TS Multiplex. It is carried
in one of four specifically identified table section constructs
[ISO-MPEG], see also SI Table.
PU: Payload Unit. A sequence of bytes sent using a TS. Examples of
Payload Units include: an MPEG-2 Table Section or a ULE SNDU.
PUSI: Payload_Unit_Start_Indicator [ISO-MPEG]. A single bit flag
carried in the TS Packet header. A PUSI value of zero indicates that
the TS Packet does not carry the start of a new Payload Unit. A PUSI
value of one indicates that the TS Packet does carry the start of a
new Payload Unit. In ULE, a PUSI bit set to 1 also indicates the
presence of a one byte Payload Pointer (PP).
Receiver: A piece of equipment that processes the signal from a TS
Multiplex and performs filtering and forwarding of encapsulated PDUs
to the network-layer service (or bridging module when operating at
the link layer).
Montpetit, et al. Informational [Page 6]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
SI Table: Service Information Table [ISO-MPEG]. In this document,
this term describes a table that is used to convey information about
the services carried in a TS Multiplex, that has been defined by
another standards body. A Table may consist of one or more Table
Sections, however all sections of a particular SI Table must be
carried over a single TS Logical Channel [ISO-MPEG].
SNDU: Sub-Network Data Unit. An encapsulated PDU sent as an MPEG-2
Payload Unit.
STB: Set-Top Box. A consumer equipment (Receiver) for reception of
digital TV services.
Table Section: A Payload Unit carrying all or a part of an SI or PSI
Table [ISO-MPEG].
TS: Transport Stream [ISO-MPEG], a method of transmission at the
MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI
reference model. See also TS Logical Channel and TS Multiplex.
TS Header: The 4-byte header of a TS Packet [ISO-MPEG].
TS Logical Channel: Transport Stream Logical Channel. In this
document, this term identifies a channel at the MPEG-2 level
[ISO-MPEG]. It exists at level 2 of the ISO/OSI reference model.
All packets sent over a TS Logical Channel carry the same PID value
(this value is unique within a specific TS Multiplex). According to
MPEG-2, some TS Logical Channels are reserved for specific
signalling. Other standards (e.g., ATSC, DVB) also reserve specific
TS Logical Channels.
TS Multiplex: In this document, this term defines a set of MPEG-2 TS
Logical Channels sent over a single lower layer connection. This may
be a common physical link (i.e., a transmission at a specified symbol
rate, FEC setting, and transmission frequency) or an encapsulation
provided by another protocol layer (e.g., Ethernet, or RTP over IP).
The same TS Logical Channel may be repeated over more than one TS
Multiplex (possibly associated with a different PID value), for
example to redistribute the same multicast content to two terrestrial
TV transmission cells.
TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex
[ISO-MPEG]. Each TS Packet carries a 4B header, plus optional
overhead including an Adaptation Field, encryption details and time
stamp information to synchronize a set of related TS Logical
Channels. It is also referred to as a TS_cell. Each TS Packet
carries a PID value to associate it with a single TS Logical Channel.
Montpetit, et al. Informational [Page 7]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
ULE: Unidirectional Lightweight Encapsulation (ULE) [IPDVB-ULE]. A
scheme that encapsulates PDUs, into SNDUs that are sent in a series
of TS Packets using a single TS Logical Channel.
3. Architecture
The following sections introduce the components of the MPEG-2
Transmission Network and relate these to a networking framework.
3.1. MPEG-2 Transmission Networks
There are many possible topologies for MPEG-2 Transmission Networks.
A number of example scenarios are briefly described below, and the
following text relates specific functions to this set of scenarios.
A) Broadcast TV and Radio Delivery
The principal service in the Broadcast TV and Radio Delivery scenario
is Digital TV and/or Radio and their associated data [MMUSIC-IMG,
ETSI-IPDC]. Such networks typically contain two components: the
contribution feed and the broadcast part. Contribution feeds provide
communication from a typically small number of individual sites
(usually at high quality) to the Hub of a broadcast network. The
traffic carried on contribution feeds is typically encrypted, and is
usually processed prior to being resent on the Broadcast part of the
network. The Broadcast part uses a star topology centered on the Hub
to reach a typically large number of down-stream Receivers. Although
such networks may provide IP transmission, they do not necessarily
provide access to the public Internet.
B) Broadcast Networks used as an ISP
Another scenario resembles that above, but includes the provision of
IP services providing access to the public Internet. The IP traffic
in this scenario is typically not related to the digital TV/Radio
content, and the service may be operated by an independent operator
such as unidirectional file delivery or bidirectional ISP access.
The IP service must adhere to the full system specification used for
the broadcast transmission, including allocation of PIDs and
generation of appropriate MPEG-2 control information (e.g., DVB and
ATSC SI tables).
C) Unidirectional Star IP Scenario
The Unidirectional Star IP Scenario utilizes a Hub station to provide
a data network delivering a common bit stream to typically medium-
sized groups of Receivers. MPEG-2 transmission technology provides
the forward direction physical and link layers for this transmission;
the return link (if required) is provided by other means. IP
Montpetit, et al. Informational [Page 8]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
services typically form the main proportion of the transmission
traffic. Such networks do not necessarily implement the MPEG-2
control plane, i.e., PSI/SI tables.
D) Datacast Overlay
The Datacast Overlay scenario employs MPEG-2 physical and link layers
to provide additional connectivity such as unidirectional multicast
to supplement an existing IP-based Internet service. Examples of
such a network includes IP Datacast to mobile wireless receivers
[MMUSIC-IMG].
E) Point-to-Point Links
Point-to-Point connectivity may be provided using a pair of transmit
and receive interfaces supporting the MPEG-2 physical and link
layers. Typically, the transmission from a sender is received by
only one or a small number of Receivers. Examples include the use of
transmit/receive DVB-S terminals to provide satellite links between
ISPs utilising BGP routing.
F) Two-Way IP Networks
Two-Way IP networks are typically satellite-based and star-based
utilising a Hub station to deliver a common bit stream to medium-
sized groups of receivers. A bidirectional service is provided over
a common air-interface. The transmission technology in the forward
direction at the physical and link layers is MPEG-2, which may also
be used in the return direction. Such systems also usually include a
control plane element to manage the (shared) return link capacity. A
concrete example is the DVB-RCS system [ETSI-DVBRCS]. IP services
typically form the main proportion of the transmission traffic.
Scenarios A-D employ unidirectional MPEG-2 Transmission Networks.
For satellite-based networks, these typically have a star topology,
with a central Hub providing service to large numbers of down-stream
Receivers. Terrestrial networks may employ several transmission
Hubs, each serving a particular coverage cell with a community of
Receivers.
From an IP viewpoint, the service is typically either unidirectional
multicast, or a bidirectional service in which some complementary
link technology (e.g., modem, Local Multipoint Distribution Service
(LMDS), General Packet Radio Service (GPRS)) is used to provide the
return path from Receivers to the Internet. In this case, routing
could be provided using UniDirectional Link Routing (UDLR) [RFC3077].
Note that only Scenarios A-B actually carry MPEG-2 video and audio
(intended for reception by digital Set Top Boxes (STBs)) as the
primary traffic. The other scenarios are IP-based data networks and
need not necessarily implement the MPEG-2 control plane.
Montpetit, et al. Informational [Page 9]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
Scenarios E-F provide two-way connectivity using the MPEG-2
Transmission Network. Such networks provide direct support for
bidirectional protocols above and below the IP layer.
The complete MPEG-2 transmission network may be managed by a
transmission service operator. In such cases, the assignment of
addresses and TS Logical Channels at Receivers are usually under the
control of the service operator. Examples include a TV operator
(Scenario A), or an ISP (Scenarios B-F). MPEG-2 transmission
networks are also used for private networks. These typically involve
a smaller number of Receivers and do not require the same level of
centralized control. Examples include companies wishing to connect
DVB-capable routers to form links within the Internet (Scenario B).
3.2. TS Logical Channels
An MPEG-2 Transport Multiplex offers a number of parallel channels,
which are known here as TS Logical Channels. Each TS Logical Channel
is uniquely identified by the Packet ID (PID) value that is carried
in the header of each MPEG-2 TS Packet. The PID value is a 13 bit
field; thus, the number of available channels ranges from 0 to 8191
decimal or 0x1FFF in hexadecimal, some of which are reserved for
transmission of SI tables. Non-reserved TS Logical Channels may be
used to carry audio [ISO-AUD], video [ISO-VID], IP packets
[ISO-DSMCC, ETSI-DAT, ATSC-DAT], or other data [ISO-DSMCC, ETSI-DAT,
ATSC-DAT]. The value 8191 decimal (0x1FFF) indicates a null packet
that is used to maintain the physical bearer bit rate when there are
no other MPEG-2 TS packets to be sent.
Montpetit, et al. Informational [Page 10]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
TS-LC-A-1 /---\--------------------/---\
\ / \ / \
\ | | | |
TS-LC-A-2 ----------- | | -------------
-------------------- | | -------------
| | | |
/-------- / | -------------
/ \----/-------------------\----/
TS-LC-A-3/ MPEG-2 TS MUX A
/
TS-LC /
------------X
\ TS-LC-B-3 /---\------------------------/---\
\ / \ / \
\ | | | |
TS-LC-B-2 \----------- | | ---------
-------------------- | | ---------
| | | |
/-------- / | ---------
/ \----/-----------------------\----/
/ MPEG-2 TS MUX B
TS-LC-B-1
Figure 2: Example showing MPEG-2 TS Logical Channels carried
Over 2 MPEG-2 TS Multiplexes.
TS Logical Channels are independently numbered on each MPEG-2 TS
Multiplex (MUX). In most cases, the data sent over the TS Logical
Channels will differ for different multiplexes. Figure 2 shows a set
of TS Logical Channels sent using two MPEG-2 TS Multiplexes (A and
B).
There are cases where the same data may be distributed over two or
more multiplexes (e.g., some SI tables; multicast content that needs
to be received by Receivers tuned to either MPEG-2 TS; unicast data
where the Receiver may be in either/both of two potentially
overlapping MPEG-2 transmission cells). In figure 2, each multiplex
carries 3 MPEG-2 TS Logical Channels. These TS Logical Channels may
differ (TS-LC-A-1, TS-LC-A-2, TS-LC-B-2, TS-LC-B-1), or may be common
to both MPEG-2 TS Multiplexes (i.e., TS-LC-A-3 and TS-LC-B-3 carry
identical content).
As can been seen, there are similarities between the way PIDs are
used and the operation of virtual channels in ATM. However, unlike
ATM, a PID defines a unidirectional broadcast channel and not a
point-to-point link. Contrary to ATM, there is, as yet, no specified
Montpetit, et al. Informational [Page 11]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
standard interface for MPEG-2 connection setup, or for signaling
mappings of IP flows to PIDs, or to set the Quality of Service, QoS,
assigned to a TS Logical Channel.
3.3. Multiplexing and Re-Multiplexing
In a simple example, one or more TS Logical Channels are processed by
an MPEG-2 multiplexor, resulting in a TS Multiplex. The TS Multiplex
is forwarded over a physical bearer towards one or more Receivers
(Figure 3).
In a more complex example, the same TS may be fed to multiple MPEG-2
multiplexors and these may, in turn, feed other MPEG-2 multiplexors
(remultiplexing). Remultiplexing may occur in several places (and is
common in Scenarios A and B of Section 3.1). One example is a
satellite that provides on-board processing of the TS packets,
multiplexing the TS Logical Channels received from one or more uplink
physical bearers (TS Multiplex) to one (or more in the case of
broadcast/multicast) down-link physical bearer (TS Multiplex). As
part of the remultiplexing process, a remultiplexor may renumber the
PID values associated with one or more TS Logical Channels to prevent
clashes between input TS Logical Channels with the same PID carried
on different input multiplexes. It may also modify and/or insert new
SI data into the control plane.
In all cases, the final result is a "TS Multiplex" that is
transmitted over the physical bearer towards the Receiver.
Montpetit, et al. Informational [Page 12]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
+------------+ +------------+
| IP | | IP |
| End Host | | End Host |
+-----+------+ +------------+
| ^
+------------>+---------------+ |
+ IP | |
+-------------+ Encapsulator | |
SI-Data | +------+--------+ |
+-------+-------+ |MPEG-2 TS Logical Channel |
| MPEG-2 | | |
| SI Tables | | |
+-------+-------+ ->+------+--------+ |
| -->| MPEG-2 | . . .
+------------>+ Multiplexor | |
MPEG-2 TS +------+--------+ |
Logical Channel |MPEG-2 TS Mux |
| |
Other ->+------+--------+ |
MPEG-2 -->+ MPEG-2 | |
TS --->+ Multiplexor | |
---->+------+--------+ |
|MPEG-2 TS Mux |
| |
+------+--------+ +------+-----+
|Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+
TS Mux
Figure 3: An example configuration for a unidirectional
Service for IP transport over MPEG-2
3.4. IP Datagram Transmission
Packet data for transmission over an MPEG-2 Transport Multiplex is
passed to an Encapsulator, sometimes known as a Gateway. This
receives Protocol Data Units, PDUs, such as Ethernet frames or IP
packets, and formats each into a Sub-Network Data Unit, SNDU, by
adding an encapsulation header and trailer (see Section 4). The
SNDUs are subsequently fragmented into a series of TS Packets.
To receive IP packets over an MPEG-2 TS Multiplex, a Receiver needs
to identify the specific TS Multiplex (physical link) and also the TS
Logical Channel (the PID value of a logical link). It is common for
a number of MPEG-2 TS Logical Channels to carry SNDUs; therefore, a
Receiver must filter (accept) IP packets sent with a number of PID
values, and must independently reassemble each SNDU.
Montpetit, et al. Informational [Page 13]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
A Receiver that simultaneously receives from several TS Logical
Channels must filter other unwanted TS Logical Channels by employing,
for example, specific hardware support. Packets for one IP flow
(i.e., a specific combination of IP source and destination addresses)
must be sent using the same PID. It should not be assumed that all
IP packets are carried on a single PID, as in some cable modem
implementations, and multiple PIDs must be allowed in the
architecture. Many current hardware filters limit the maximum number
of active PIDs (e.g., 32), although if needed, future systems may
reasonably be expected to support more.
In some cases, Receivers may need to select TS Logical Channels from
a number of simultaneously active TS Multiplexes. To do this, they
need multiple physical receive interfaces (e.g., radio frequency (RF)
front-ends and demodulators). Some applications also envisage the
concurrent reception of IP Packets over other media that may not
necessarily use MPEG-2 transmission.
Bidirectional (duplex) transmission can be provided using an MPEG-2
Transmission Network by using one of a number of alternate return
channel schemes [ETSI-RC]. Duplex IP paths may also be supported
using non-MPEG-2 return links (e.g., in Scenarios B-D of section
3.1). One example of such an application is that of UniDirectional
Link Routing, UDLR [RFC3077].
3.5. Motivation
The network layer protocols to be supported by this architecture
include:
(i) IPv4 Unicast packets, destined for a single end host
(ii) IPv4 Broadcast packets, sent to all end systems in an IP
network
(iii) IPv4 Multicast packets
(iv) IPv6 Unicast packets, destined for a single end host
(v) IPv6 Multicast packets
(vi) Packets with compressed IPv4 / IPv6 packet headers (e.g.,
[RFC2507, RFC3095])
(vii) Bridged Ethernet frames
(viii) Other network protocol packets (MPLS, potential new protocols)
Montpetit, et al. Informational [Page 14]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
The architecture will provide:
(i) Guidance on which MPEG-2 features are pre-requisites for the
IP service, and identification of any optional fields that
impact performance/correct operation.
(ii) Standards to provide an efficient and flexible encapsulation
scheme that may be easily implemented in an Encapsulator or
Receiver. The payload encapsulation requires a type field for
the SNDU to indicate the type of packet and a mechanism to
signal which encapsulation is used on a certain PID.
(iii) Standards to associate a particular IP address with a Network
Point of Attachment (NPA) that could or may not be a MAC
Address. This process resembles the IPv4 Address Resolution
Protocol, ARP, or IPv6 Neighbor Discovery, ND, protocol
[IPDVB-AR]. In addition, the standard will be compatible with
IPv6 autoconfiguration.
(iv) Standards to associate an MPEG-2 TS interface with one or more
specific TS Logical Channels (PID, TS Multiplex). Bindings
are required for both unicast transmission, and multicast
reception. In the case of IPv4, this must also support
network broadcast. To make the schemes robust to loss and
state changes within the MPEG-2 transmission network, a soft-
state approach may prove desirable.
(v) Standards to associate the capabilities of an MPEG-2 TS
Logical Channel with IP flows. This includes mapping of QoS
functions, such as IP QoS/DSCP and RSVP, to underlying MPEG-2
TS QoS, multi-homing and mobility. This capability could be
associated by the AR standard proposed above.
(vi) Guidance on Security for IP transmission over MPEG-2. The
framework must permit use of IPsec and clearly identify any
security issues concerning the specified protocols. The
security issues need to consider two cases: unidirectional
transfer (in which communication is only from the sending IP
end host to the receiving IP end host) and bidirectional
transfer. Consideration should also be given to security of
the TS Multiplex: the need for closed user groups and the use
of MPEG-2 TS encryption.
(vii) Management of the IP transmission, including standardized SNMP
MIBs and error reporting procedures. The need for and scope
of this is to be determined.
Montpetit, et al. Informational [Page 15]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
The specified architecture and techniques should be suited to a range
of systems employing the MPEG-2 TS, and may also suit other
(sub)networks offering similar transfer capabilities.
The following section, 4, describes encapsulation issues. Sections 5
and 6 describe address resolution issues for unicast and multicast,
respectively.
4. Encapsulation Protocol Requirements
This section identifies requirements and provides examples of
mechanisms that may be used to perform the encapsulation of IPv4/v6
unicast and multicast packets over MPEG-2 Transmission Networks.
A network device, known as an Encapsulator receives PDUs (e.g., IP
Packets or Ethernet frames) and formats these into Subnetwork Data
Units, SNDUs. An encapsulation (or convergence) protocol transports
each SNDU over the MPEG-2 TS service and provides the appropriate
mechanisms to deliver the encapsulated PDU to the Receiver IP
interface.
In forming an SNDU, the encapsulation protocol typically adds header
fields that carry protocol control information, such as the length of
SNDU, Receiver address, multiplexing information, payload type,
sequence numbers, etc. The SNDU payload is typically followed by a
trailer, which carries an Integrity Check (e.g., Cyclic Redundancy
Check, CRC). Some protocols also add additional control information
and/or padding to or after the trailer (figure 4).
+--------+-------------------------+-----------------+
| Header | PDU | Integrity Check |
+--------+-------------------------+-----------------+
<--------------------- SNDU ------------------------->
Figure 4: Encapsulation of a subnetwork PDU (e.g., IPv4 or IPv6
packet) to form an MPEG-2 Payload Unit.
Examples of existing encapsulation/convergence protocols include ATM
AAL5 [ITU-AAL5] and MPEG-2 MPE [ETSI-DAT].
When required, an SNDU may be fragmented across a number of TS
Packets (figure 5).
Montpetit, et al. Informational [Page 16]
| +--ro instance-level? level
| +--ro interface-name? string
| +--ro interface-level? level
| +--ro extended-circuit-id? extended-circuit-id
| +--ro lsp-id? lsp-id
| +--ro sequence? uint32
| +--ro received-timestamp? yang:timestamp
| +--ro neighbor-system-id? system-id
+---n lsp-generation
+--ro instance-name? string
+--ro instance-level? level
+--ro lsp-id? lsp-id
+--ro sequence? uint32
+--ro send-timestamp? yang:timestamp
5. Interaction with Other YANG Modules
The "isis" configuration container augments the "/rt:routing/
rt:routing-instance/rt:routing-protocols/routing-protocol" container
of the ietf-routing module by defining ISIS specific parameters.
The "isis" operational state container augments the "/rt:routing-
state/rt:routing-instance/rt:routing-protocols/routing-protocol"
container of the ietf-routing module by defining ISIS specific
operational states.
Some ISIS specific routes attributes are added to route objects of
the ietf-routing module by augmenting "/rt:routing-
state/rt:ribs/rt:rib/rt:routes/rt:route" and "/rt:active-
route/rt:output/rt:route".
6. YANG Module
<CODE BEGINS> file "ietf-isis@2014-10-24.yang"
module ietf-isis {
namespace "urn:ietf:params:xml:ns:yang:ietf-isis";
prefix isis;
import ietf-routing {
prefix "rt";
}
import ietf-inet-types {
prefix inet;
}
Litkowski, et al. Expires April 27, 2015 [Page 20]
Internet-Draft isis-cfg October 2014
import ietf-yang-types {
prefix yang;
}
organization
"IETF ISIS Working Group";
contact
"WG List: <mailto:isis-wg@ietf.org>
Editor: Stephane Litkowski
<mailto:stephane.litkowski@orange.com>
Derek Yeung
<mailto:myeung@cisco.com>
Acee Lindem
<mailto:acee@cisco.com>
Jeffrey Zhang
<mailto:zzhang@juniper.net>
Ladislav Lhotka
<mailto:llhotka@nic.cz>
Yi Yang
<mailto:yiya@cisco.com>
Dean Bogdanovic
<mailto:deanb@juniper.net>
Kiran Agrahara Sreenivasa
<mailto:kkoushik@brocade.com>
Yingzhen Qu
<mailto:yiqu@cisco.com>
";
description
"The YANG module defines a generic configuration model for
ISIS common across all of the vendor implementations.";
revision 2014-10-24 {
description
"
* Change hello-padding to container
* Change bfd to container
* Make BFD a feature
* Creates mpls-te container and put router-id
inside
* Remove GR helper disable and timers
";
reference "draft-ietf-isis-yang-isis-cfg-01";
}
Litkowski, et al. Expires April 27, 2015 [Page 21]
Internet-Draft isis-cfg October 2014
revision 2014-10-21 {
description
"
* Interface metric move from af container to interface
container
* Hello-padding on interface moved to hello-padding-disable
with empty type
* three-way-handshake removed
* route preference changed to a choice
* csnp-authentication/psnp-authentication merged
to authentication container
* lsp-gen-interval-exp-delay removed
* Added overload-max-metric feature
* overload-max-metric is in a separate container
";
reference "";
}
revision 2014-10-07 {
description
"
* Removed spf parameters (should be part of
vendor specific extensions.
* Removed hello parameters at global level.
* Interface configuration uses a string rather
than a reference. This permits to map to some
vendor specific configuration.
";
reference "draft-ietf-isis-yang-isis-00";
}
revision 2014-09-26 {
description
"
* Add BFD support
* remove max-elements to max-area-addresses
";
reference "";
}
revision 2014-09-11 {
description
"
* Add level parameter to ispf and spf delay
* Add LSP generation as a feature
* Make lsp-refresh a feature
* Change parameter container to list
";
reference "";
}
Litkowski, et al. Expires April 27, 2015 [Page 22]
Internet-Draft isis-cfg October 2014
revision 2014-09-05 {
description
" Rewrite of the global hierarchy.";
reference "";
}
revision 2014-08-06 {
description
"
* isis-state renamed to isis.
* Add GR support
* Add meshgroup support
* Add CLNS support
* Add 64bits tags
* Add notifications to be aligned with MIB4444
* Add packet-counters, interface-counters, system-counters
states
* Add 3-way handshake support
* Rename isis-adjacency-updown to adjacency-change
* Add notification for LSP reception
* Use feature for reference BW
* Add lsp-retransmit-interval on interfaces
* Rename lsp-interval to lsp-pacing-interval
* Add ispf support as feature
* Add spf delay support as feature (2step & exp backoff)
* Add maximum-area-addresses
* Add default-metric
";
reference "RFC XXXX: YANG Data Model for ISIS Protocol";
}
revision 2014-06-25 {
description "
* isis-cfg renamed to isis.
* Add precisions on authentication-keys in description
";
reference "draft-litkowski-isis-yang-isis-01";
}
revision 2014-06-20 {
description "
* isis-op renamed to isis-state.
* Multiple instances under ISIS are removed.
* interface-cfg grouping removed and content
is directly included in container isis.
* TLVxx renamed with human-readable name in isis-database.
TLV reference are putted in description.
* Reference to core routing module were fixed.
* Namespace fixed.
* Add simple-iso-address type.
Litkowski, et al. Expires April 27, 2015 [Page 23]
Internet-Draft isis-cfg October 2014
* area-id and system-id in ISIS container are merged to
nsap-address.
* Add isis-system-id type.
* Add isis-lsp-id type.
* Add remaining-lifetime leaf in isis-database.
* Add TLV2 (is-neighbor) in isis-database.
* Renamed some container name for consistency
reason ('isis-' prefixed).
* Add new identities isis-cfg and isis-state.
* Add descriptions.
* Add notification isis-adjacency-updown.
* Add RPC clear-isis-adjacency and clear-isis-database.
";
reference "draft-litkowski-isis-yang-isis-00";
}
revision 2014-06-11 {
description "Initial revision.";
reference "draft-litkowski-netmod-isis-cfg-00";
}
identity isis {
base rt:routing-protocol;
description "Identity for the ISIS routing protocol.";
}
identity isis-adjacency-change {
description "Identity for the ISIS routing protocol
adjacency state.";
}
identity clear-isis-database {
description "Identity for the ISIS routing protocol
database reset action.";
}
identity clear-isis-adjacency {
description "Identity for the ISIS routing protocol
adjacency reset action.";
}
feature bfd {
description
"Support of BFD.";
}
feature overload-max-metric {
description
"Support of overload by setting
all links to max metric.";
Litkowski, et al. Expires April 27, 2015 [Page 24]
Internet-Draft isis-cfg October 2014
}
feature prefix-tag {
description
"Add 32bit tag to prefixes";
}
feature prefix-tag64 {
description
"Add 64bit tag to prefixes";
}
feature reference-bandwidth {
description
"Use a reference bandwidth to compute metric.";
}
feature ipv4-router-id {
description
"Support of IPv4 router ID configuration under ISIS.";
}
feature ipv6-router-id {
description
"Support of IPv6 router ID configuration under ISIS.";
}
feature multi-topology {
description
"Multitopology routing support.";
}
feature nlpid-control {
description
"This feature controls the advertisement
of support NLPID within ISIS configuration.";
}
feature graceful-restart {
description
"Graceful restart support as per RFC5306.";
}
feature lsp-refresh {
description
"Configuration of LSP refresh interval.";
}
feature maximum-area-addresses {
description
"Support of maximum-area-addresses config.";
}
RFC 4259 IP Transport over MPEG-2 Networks November 2005
+-----------------------------------------+
|Encap Header|SubNetwork Data Unit (SNDU) |
+-----------------------------------------+
/ / \ \
/ / \ \
/ / \ \
+------+----------+ +------+----------+ +------+----------+
|MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 |
|Header| Payload | |Header| Payload | |Header| Payload |
+------+----------+ +------+----------+ +------+----------+
Figure 5: Encapsulation of a PDU (e.g., IP packet) into a
Series of MPEG-2 TS Packets. Each TS Packet carries
a header with a common Packet ID (PID) value denoting
the MPEG-2 TS Logical Channel.
The DVB family of standards currently defines a mechanism for
transporting an IP packet, or Ethernet frame using the Multi-Protocol
Encapsulation (MPE) [ETSI-DAT]. An equivalent scheme is also
supported in ATSC [ATSC-DAT, ATSC-DATG]. It allows transmission of
IP packets or (by using LLC) Ethernet frames by encapsulation within
a Table Section (with the format used by the control plane associated
with the MPEG-2 transmission). The MPE specification includes a set
of optional header components and requires decoding of the control
headers. This processing is suboptimal for Internet traffic, since
it incurs significant receiver processing overhead and some extra
link overhead [CLC99].
The existing standards carry heritage from legacy implementations.
These have reflected the limitations of technology at the time of
their deployment (e.g., design decisions driven by audio/video
considerations rather than IP networking requirements). IPv6, MPLS,
and other network-layer protocols are not natively supported.
Together, these justify the development of a new encapsulation that
will be truly IP-centric. Carrying IP packets over a TS Logical
Channel involves several convergence protocol functions. This
section briefly describes these functions and highlights the
requirements for a new encapsulation.
4.1. Payload Unit Delimitation
MPEG-2 indicates the start of a Payload Unit (PU) in a new TS Packet
with a "payload_unit_start_indicator" (PUSI) [ISO-MPEG] carried in
the 4B TS Packet header. The PUSI is a 1 bit flag that has normative
meaning [ISO-MPEG] for TS Packets that carry PES Packets or PSI/SI
data.
Montpetit, et al. Informational [Page 17]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
When the payload of a TS Packet contains PES data, a PUSI value of
'1' indicates the TS Packet payload starts with the first byte of a
PES Packet. A value of '0' indicates that no PES Packet starts in
the TS Packet. If the PUSI is set to '1', then one, and only one,
PES Packet starts in the TS Packet.
When the payload of the TS Packet contains PSI data, a PUSI value of
'1' indicates the first byte of the TS Packet payload carries a
Payload Pointer (PP) that indicates the position of the first byte of
the Payload Unit (Table Section) being carried; if the TS Packet does
not carry the first byte of a Table Section, the PUSI is set to '0',
indicating that no Payload Pointer is present.
Using this PUSI bit, the start of the first Payload Unit in a TS
Packet is exactly known by the Receiver, unless that TS Packet has
been corrupted or lost in the transmission. In which case, the
payload is discarded until the next TS Packet is received with a PUSI
value of '1'.
The encapsulation should allow packing of more than one SNDU into the
same TS Packet and should not limit the number of SNDUs that can be
sent in a TS Packet. In addition, it should allow an IP Encapsulator
to insert padding when there is an incomplete TS Packet payload. A
mechanism needs to be identified to differentiate this padding from
the case where another encapsulated SNDU follows.
A combination of the PUSI and a Length Indicator (see below) allows
an efficient MPEG-2 convergence protocol to receive accurate
delineation of packed SNDUs. The MPEG-2 standard [ISO-MPEG] does not
specify how private data should use the PUSI bit.
4.2. Length Indicator
Most services using MPEG-2 include a length field in the Payload Unit
header to allow the Receiver to identify the end of a Payload Unit
(e.g., PES Packet, Section, or an SNDU).
When parts of more than two Payload Units are carried in the same TS
Packet, only the start of the first is indicated by the Payload
Pointer. Placement of a Length Indicator in the encapsulation header
allows a Receiver to determine the number of bytes until the start of
the next encapsulated SNDU. This placement also provides the
opportunity for the Receiver to pre-allocate an appropriate-sized
memory buffer to receive the reassembled SNDU.
A Length Indicator is required, and should be carried in the
encapsulation header. This should support SNDUs of at least the MTU
size offered by Ethernet (currently 1500 bytes). Although the IPv4
Montpetit, et al. Informational [Page 18]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
and IPv6 packet format permits an IP packet of size up to 64 KB, such
packets are seldom seen on the current Internet. Since high speed
links are often limited by the packet forwarding rate of routers,
there has been a tendency for Internet core routers to support MTU
values larger than 1500 bytes. A value of 16 KB is not uncommon in
the core of the current Internet. This would seem a suitable maximum
size for an MPEG-2 transmission network.
4.3. Next Level Protocol Type
Any IETF-defined encapsulation protocol should identify the payload
type being transported (e.g., to differentiate IPv4, IPv6, etc).
Most protocols use a type field to identify a specific process at the
next higher layer that is the originator or the recipient of the
payload (SNDU). This method is used by IPv4, IPv6, and also by the
original Ethernet protocol (DIX). OSI uses the concept of a
'Selector' for this, (e.g., in the IEEE 802/ISO 8802 standards for
CSMA/CD [LLC]; although in this case, a SNAP (subnetwork access
protocol) header is also required for IP packets.
A Next Level Protocol Type field is also required if compression
(e.g., Robust Header Compression [RFC3095]) is supported. No
compression method has currently been defined that is directly
applicable to this architecture, however the ROHC framework defines a
number of header compression techniques that may yield considerable
improvement in throughput on links that have a limited capacity.
Since many MPEG-2 Transmission Networks are wireless, the ROHC
framework will be directly applicable for many applications. The
benefit of ROHC is greatest for smaller SNDUs but does imply the need
for additional processing at the Receiver to expand the received
compressed packets. The selected type field should contain
sufficient code points to support this technique.
It is thus a requirement to include a Next Level Protocol Type field
in the encapsulation header. Such a field should specify values for
at least IPv4, IPv6, and must allow for other values (e.g., MAC-level
bridging).
4.4. L2 Subnet Addressing
In MPEG-2, the PID carried in the TS Packet header is used to
identify individual services with the help of SI tables. This was
primarily intended as a unidirectional (simplex) broadcast system. A
TS Packet stream carries either tables or one PES Packet stream
(i.e., compressed video or audio). Individual Receivers are not
addressable at this level.
Montpetit, et al. Informational [Page 19]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
IPv4 and IPv6 allocate addresses to end hosts and intermediate
systems (routers). Each system (or interface) is identified by a
globally assigned address. ISO uses the concept of a hierarchically
structured Network Service Access Point (NSAP) address to identify an
end host user process in an Internet environment.
Within a local network, a completely different set of addresses for
the Network Point of Attachment (NPA) is used; frequently these NPA
addresses are referred to as Medium Access Control, MAC-level
addresses. In the Internet they are also called hardware addresses.
Whereas network layer addresses are used for routing, NPA addresses
are primarily used for Receiver identification.
Receivers may use the NPA of a received SNDU to reject unwanted
unicast packets within the (software) interface driver at the
Receiver, but must also perform forwarding checks based on the IP
address. IP multicast and broadcast may also filter using the NPA,
but Receivers must also filter unwanted packets at the network layer
based on source and destination IP addresses. This does not imply
that each IP address must map to a unique NPA (more than one IP
address may map to the same NPA). If a separate NPA address is not
required, the IP address is sufficient for both functions.
If it is required to address an individual Receiver in an MPEG-2
transport system, this can be achieved either at the network level
(IP address) or via a hardware-level NPA address (MAC-address). If
both addresses are used, they must be mapped in either a static or a
dynamic way (e.g., by an address resolution process). A similar
requirement may also exist to identify the PID and TS multiplex on
which services are carried.
Using an NPA address in an MPEG-2 TS may enhance security, in that a
particular PDU may be targeted for a particular Receiver by
specifying the corresponding Receiver NPA address. However, this is
only a weak form of security, since the NPA filtering is often
reconfigurable (frequently performed in software), and may be
modified by a user to allow reception of specified (or all) packets,
similar to promiscuous mode operation in Ethernet. If security is
required, it should be applied at another place (e.g., link
encryption, authentication of address resolution, IPsec, transport
level security and/or application level security).
There are also cases where the use of an NPA is required (e.g., where
a system operates as a router) and, if present, this should be
carried in an encapsulation header where it may be used by Receivers
as a pre-filter to discard unwanted SNDUs. The addresses allocated
do not need to conform to the IEEE MAC address format. There are
many cases where an NPA is not required, and network layer filtering
Montpetit, et al. Informational [Page 20]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
may be used. Therefore, a new encapsulation protocol should support
an optional NPA.
4.5. Integrity Check
For the IP service, the probability of undetected packet error should
be small (or negligible) [RFC3819]. Therefore, there is a need for a
strong integrity check (e.g., Cyclic Redundancy Check or CRC) to
verify correctness of a received PDU [RFC3819]. Such checks should
be sufficient to detect incorrect operation of the encapsulator and
Receiver (including reassembly errors following loss/corruption of TS
Packets), in addition to protecting from loss and/or corruption by
the transmission network (e.g., multiplexors and links).
Mechanisms exist in MPEG-2 Transmission Networks that may assist in
detecting loss (e.g., the 4-bit continuity counter included in the
MPEG-2 TS Packet header).
An encapsulation must provide a strong integrity check for each IP
packet. The requirements for usage of a link CRC are provided in
[RFC3819]. To ease hardware implementation, this check should be
carried in a trailer following the SNDU. A CRC-32 is sufficient for
operation with up to a 12 KB payload, and may still provide adequate
protection for larger payloads.
4.6. Identification of Scope.
The MPE section header contains information that could be used by the
Receiver to identify the scope of the (MAC) address carried as an
NPA, and to prevent TS Packets intended for one scope from being
received by another. Similar functionality may be achieved by
ensuring that only IP packets that do not have overlapping scope are
sent on the same TS Logical Channel. In some cases, this may imply
the use of multiple TS Logical Channels.
4.7. Extension Headers
The evolution of the Internet service may require additional
functions in the future. A flexible protocol should therefore
provide a way to introduce new features when required, without having
to provide additional out-of-band configuration.
IPv6 introduced the concept of extension headers that carry extra
information necessary/desirable for certain subnetworks. The DOCSIS
cable specification also allows a MAC header to carry extension
headers to build operator-specific services. Thus, it is a
requirement for the new encapsulation to allow extension headers.
Montpetit, et al. Informational [Page 21]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
4.8. Summary of Requirements for Encapsulation
The main requirements for an IP-centric encapsulation include:
- support of IPv4 and IPv6 packets
- support for Ethernet encapsulated packets
- flexibility to support other IP formats and protocols (e.g.,
ROHC, MPLS)
- easy implementation using either hardware or software
processing
- low overhead/managed overhead
- a fully specified algorithm that allows a sender to pack
multiple packets per SNDU and to easily locate packet
fragments
- extensibility
- compatibility with legacy deployments
- ability to allow link encryption, when required
- capability to support a full network architecture including
data, control, and management planes
5. Address Resolution Functions
Address Resolution (AR) provides a mechanism that associates layer 2
(L2) information with the IP address of a system [IPDVB-AR]. Many L2
technologies employ unicast AR at the sender: an IP system wishing to
send an IP packet encapsulates it and places it into an L2 frame. It
then identifies the appropriate L3 adjacency (e.g., next hop router,
end host) and determines the appropriate L2 adjacency (e.g., MAC
address in Ethernet) to which the frame should be sent so that the
packet gets across the L2 link.
The L2 addresses discovered using AR are normally recorded in a data
structure known as the arp/neighbor cache. The results of previous
AR requests are usually cached. Further AR protocol exchanges may be
required as communication proceeds to update or re-initialize the
client cache state contents (i.e., purge/refresh the contents). For
stability, and to allow network topology changes and client faults,
the cache contents are normally "soft state"; that is, they are aged
with respect to time and old entries are removed.
In some cases (e.g., ATM, X.25, MPEG-2 and many more), AR involves
finding other information than the MAC address. This includes
identifying other parameters required for L2 transmission, such as
channel IDs (VCs in X.25, VCIs in ATM, or PIDs in MPEG-2 TS).
Montpetit, et al. Informational [Page 22]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
Address resolution has different purposes for unicast and multicast.
Multicast address resolution is not required for many L2 networks,
but is required where MPEG-2 transmission networks carry IP multicast
packets using more than one TS Logical Channel.
5.1. Address Resolution for MPEG-2
There are three elements to the L2 information required to perform AR
before an IP packet is sent over an MPEG-2 TS. These are:
(i) A Receiver ID (e.g., a 6B MAC/NPA address).
(ii) A PID or index to find a PID.
(iii) Tuner information (e.g., Transmit Frequency of the
physical layer of a satellite/broadcast link
Elements (ii) and (iii) need to be de-referenced when the MPEG-2
Transmission Network includes (re)multiplexors that renumber the PID
values of the TS Logical Channels that they process. In MPEG-2
[ISO-MPEG], this dereferencing is via indexes to the information
(i.e., the Program Map Table, PMT, which is itself indexed via the
Program Association Table, PAT). (Note that PIDs are not intended to
be end-to-end identifiers.) However, although remultiplexing is
common in broadcast TV networks (scenarios A and B), many private
networks do not need to employ multiplexors that renumber PIDs (see
Section 3.3).
The third element (iii) allows an AR client to resolve to a different
MPEG TS Multiplex. This is used when there are several channels that
may be used for communication (i.e., multiple outbound/inbound
links). In a mesh system, this could be used to determine
connectivity. This AR information is used in two ways at a Receiver:
(i) AR resolves an IP unicast or IPv4 broadcast address to the (MPEG
TS Multiplex, PID, MAC/NPA address). This allows the Receiver
to set L2 filters to let traffic pass to the IP layer. This is
used for unicast, and IPv4 subnet broadcast.
(ii) AR resolves an IP multicast address to the (MPEG TS Multiplex,
PID, MAC/NPA address), and allows the Receiver to set L2 filters
enabling traffic to pass to the IP layer. A Receiver in an
MPEG-2 TS Transmission Network needs to resolve the PID value
and the tuning (if present) associated with a TS Logical Channel
and (at least for unicast) the destination Receiver NPA address.
A star topology MPEG-2 TS transmission network is illustrated below,
with two Receivers receiving a forward broadcast channel sent by a
Hub. (A mesh system has some additional cases.) The forward
broadcast channel consists of a "TS Multiplex" (a single physical
Montpetit, et al. Informational [Page 23]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
Litkowski, et al. Expires April 27, 2015 [Page 25]
Internet-Draft isis-cfg October 2014
typedef instance-state-ref {
type leafref {
path "/rt:routing-state/rt:routing-instance/"
+"rt:routing-protocols/rt:routing-protocol/rt:name";
}
description
"This type is used for leaves that reference state data of
an ISIS protocol instance.";
}
typedef admin-state {
type enumeration {
enum "up" {
description
"Up state";
}
enum "down" {
description
"Down state";
}
}
description
"Administrative state of a component.";
}
typedef oper-state {
type enumeration {
enum "up" {
description
"Up state";
}
enum "down" {
description
"Down state";
}
}
description
"Operational state of a component.";
}
typedef circuit-id {
type uint8;
description
"This type defines the circuit ID
associated with an interface.";
}
typedef extended-circuit-id {
type uint32;
description
Litkowski, et al. Expires April 27, 2015 [Page 26]
Internet-Draft isis-cfg October 2014
"This type defines the extended circuit ID
associated with an interface.";
}
typedef interface-type {
type enumeration {
enum broadcast {
description "Broadcast interface type.
Would result in DIS election.";
}
enum point-to-point {
description
"Point to point interface type.";
}
}
description
"This type defines the type of adjacency
to be established on the interface.
This is affecting the type of hello
message that would be used.";
}
typedef authentication-type {
type enumeration {
enum none {
description "No authentication used.";
}
enum plaintext {
description "Plain text password used.";
}
enum message-digest {
description "MD5 digest used.";
}
}
description
"This type defines available authentication types.";
}
typedef level {
type enumeration {
enum "level-1" {
description
"This enum describes L1 only capability.";
}
enum "level-2" {
description
"This enum describes L2 only capability.";
}
Litkowski, et al. Expires April 27, 2015 [Page 27]
Internet-Draft isis-cfg October 2014
enum "level-all" {
description
"This enum describes both levels capability.";
}
}
default "level-all";
description
"This type defines ISIS level of an object.";
}
typedef level-number {
type uint8 {
range "1 .. 2";
}
description
"This type defines a current ISIS level.";
}
typedef lsp-id {
type string {
pattern
'[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]'
+'{4}\.[0-9][0-9]-[0-9][0-9]';
}
description
"This type defines ISIS LSP ID using pattern,
system id looks like : 0143.0438.AeF0.02-01";
}
typedef area-address {
type string {
pattern '[0-9A-Fa-f]{2}\.([0-9A-Fa-f]{4}\.){0,3}';
}
description
"This type defines the area address.";
}
typedef snpa {
type string {
length "0 .. 20";
}
description
"This type defines Subnetwork Point of Attachement format.";
}
Litkowski, et al. Expires April 27, 2015 [Page 28]
Internet-Draft isis-cfg October 2014
typedef system-id {
type string {
pattern
'[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.[0-9A-Fa-f]{4}\.00';
}
description
"This type defines ISIS system id using pattern,
system id looks like : 0143.0438.AeF0.00";
}
typedef wide-metric {
type uint32 {
range "0 .. 16777215";
}
description
"This type defines wide style format
of ISIS metric.";
}
typedef std-metric {
type uint8 {
range "0 .. 63";
}
description
"This type defines old style format
of ISIS metric.";
}
typedef mesh-group-state {
type enumeration {
enum "meshInactive" {
description
"Interface is not part of a mesh group.";
}
enum "meshSet" {
description
"Interface is part of a mesh group.";
}
enum "meshBlocked" {
description
"LSPs must not be flooded over that interface.";
}
}
description
"This type describes meshgroup state of an interface";
}
grouping notification-instance-hdr {
Litkowski, et al. Expires April 27, 2015 [Page 29]
Internet-Draft isis-cfg October 2014
description
"This group describes common instance specific
data for notifications.";
leaf instance-name {
type string;
description
"Describes the name of the ISIS instance.";
}
leaf instance-level {
type level;
description
"Describes the ISIS level of the instance.";
}
}
grouping notification-interface-hdr {
description
"This group describes common interface specific
data for notifications.";
leaf interface-name {
type string;
description
"Describes the name of the ISIS interface.";
}
leaf interface-level {
type level;
description
"Describes the ISIS level of the interface.";
}
leaf extended-circuit-id {
type extended-circuit-id;
description
"Describes the extended circuit-id of the interface.";
}
}
grouping route-content {
description
"This group add isis-specific route properties.";
leaf metric {
type uint32;
description
"This leaf describes ISIS metric of a route.";
}
leaf-list tag {
type uint64;
description
"This leaf describes list of tags associated
Litkowski, et al. Expires April 27, 2015 [Page 30]
Internet-Draft isis-cfg October 2014
with the route. The leaf describes both
32bits and 64bits tags.";
}
leaf route-type {
type enumeration {
enum l2-up-internal {
description "Level 2 internal route
and not leaked to a lower level";
}
enum l1-up-internal {
description "Level 1 internal route
and not leaked to a lower level";
}
enum l2-up-external {
description "Level 2 external route
and not leaked to a lower level";
}
enum l1-up-external {
description "Level 1 external route
and not leaked to a lower level";
}
enum l2-down-internal {
description "Level 2 internal route
and leaked to a lower level";
}
enum l1-down-internal {
description "Level 1 internal route
and leaked to a lower level";
}
enum l2-down-external {
description "Level 2 external route
and leaked to a lower level";
}
enum l1-down-external {
description "Level 1 external route
and leaked to a lower level";
}
}
description
"This leaf describes the type of ISIS route.";
}
}
augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" {
when "rt:source-protocol = 'isis:isis'" {
description "ISIS-specific route attributes.";
}
uses route-content;
Litkowski, et al. Expires April 27, 2015 [Page 31]
Internet-Draft isis-cfg October 2014
description
"This augments route object in RIB with ISIS-specific
attributes.";
}
augment "/rt:active-route/rt:output/rt:route"
{
uses route-content;
description "ISIS-specific route attributes.";
}
grouping prefix-ipv4-std {
description
"This group defines attributes of an
IPv4 standard prefix.";
leaf up-down {
type boolean;
description
"This leaf expresses the value of up/down bit.";
}
leaf i-e {
type boolean;
description
"This leaf expresses the value of I/E bit.";
}
leaf ip-prefix {
type inet:ipv4-address;
description
"This leaf describes the IPv4 prefix";
}
leaf prefix-len {
type uint8;
description
"This leaf describes the IPv4 prefix len in bits";
}
leaf default-metric {
type std-metric;
description
"This leaf describes the ISIS default metric value";
}
container delay-metric {
leaf metric {
type std-metric;
description
"This leaf describes the ISIS delay metric value";
}
leaf supported {
Litkowski, et al. Expires April 27, 2015 [Page 32]
Internet-Draft isis-cfg October 2014
type boolean;
default "false";
description
"This leaf describes if the metric is supported.";
}
description
"This container defines the ISIS delay metric.";
}
container expense-metric {
leaf metric {
type std-metric;
description
"This leaf describes the ISIS expense metric value";
}
leaf supported {
type boolean;
default "false";
description
"This leaf describes if the metric is supported.";
}
description
"This container defines the ISIS expense metric.";
}
container error-metric {
leaf metric {
type std-metric;
description
"This leaf describes the ISIS error metric value";
}
leaf supported {
type boolean;
default "false";
description
"This leaf describes if the metric is supported.";
}
description
"This container defines the ISIS error metric.";
}
}
grouping prefix-ipv4-extended {
description
"This group defines attributes of an
IPv4 extended prefix.";
leaf up-down {
type boolean;
Litkowski, et al. Expires April 27, 2015 [Page 33]
Internet-Draft isis-cfg October 2014
description
"This leaf expresses the value of up/down bit.";
}
leaf ip-prefix {
type inet:ipv4-address;
description
"This leaf describes the IPv4 prefix";
}
leaf prefix-len {
type uint8;
description
"This leaf describes the IPv4 prefix len in bits";
}
leaf metric {
type wide-metric;
description
"This leaf describes the ISIS metric value";
}
leaf-list tag {
type uint32;
description
"This leaf describes a list of tags associated with
the prefix.";
}
leaf-list tag64 {
type uint64;
description
"This leaf describes a list of 64-bit tags associated with
the prefix.";
}
}
grouping prefix-ipv6-extended {
description
"This group defines attributes of an
IPv6 prefix.";
leaf up-down {
type boolean;
description
"This leaf expresses the value of up/down bit.";
}
leaf ip-prefix {
type inet:ipv6-address;
description
"This leaf describes the IPv6 prefix";
}
leaf prefix-len {
Litkowski, et al. Expires April 27, 2015 [Page 34]
Internet-Draft isis-cfg October 2014
type uint8;
description
"This leaf describes the IPv4 prefix len in bits";
}
leaf metric {
type wide-metric;
description
"This leaf describes the ISIS metric value";
}
leaf-list tag {
type uint32;
description
"This leaf describes a list of tags associated with
the prefix.";
}
leaf-list tag64 {
type uint64;
description
"This leaf describes a list of 64-bit tags associated with
the prefix.";
}
}
grouping neighbor-extended {
description
"This group defines attributes of an
ISIS extended neighbor.";
leaf neighbor-id {
type system-id;
description
"This leaf describes the system-id of the neighbor.";
}
leaf metric {
type wide-metric;
description
"This leaf describes the ISIS metric value";
}
}
grouping neighbor {
description
"This group defines attributes of an
ISIS standard neighbor.";
leaf neighbor-id {
type system-id;
description
"This leaf describes the system-id of the neighbor.";
Litkowski, et al. Expires April 27, 2015 [Page 35]
Internet-Draft isis-cfg October 2014
}
leaf i-e {
type boolean;
description
"This leaf expresses the value of I/E bit.";
}
leaf default-metric {
type std-metric;
description
"This leaf describes the ISIS default metric value";
}
container delay-metric {
leaf metric {
type std-metric;
description
"This leaf describes the ISIS delay metric value";
}
leaf supported {
type boolean;
default "false";
description
"This leaf describes if the metric is supported.";
}
description
"This container defines the ISIS delay metric.";
}
container expense-metric {
leaf metric {
type std-metric;
description
"This leaf describes the ISIS delay expense value";
}
leaf supported {
type boolean;
default "false";
description
"This leaf describes if the metric is supported.";
}
description
"This container defines the ISIS expense metric.";
}
container error-metric {
leaf metric {
type std-metric;
description
"This leaf describes the ISIS error metric value";
}
leaf supported {
Litkowski, et al. Expires April 27, 2015 [Page 36]
Internet-Draft isis-cfg October 2014
type boolean;
default "false";
description
"This leaf describes if the metric is supported.";
}
description
"This container defines the ISIS error metric.";
}
}
grouping database {
description
"This group defines attributes of an
ISIS database (Link State DB).";
leaf lsp-id {
type lsp-id;
description
"This leaf describes the LSP ID of the LSP.";
}
leaf checksum {
type uint16;
description
"This leaf describes the checksum of the LSP.";
}
leaf remaining-lifetime {
type uint16;
units "seconds";
description
"This leaf describes the remaining lifetime
in seconds before the LSP expiration.";
}
leaf sequence {
type uint32;
description
"This leaf describes the sequence number of the LSP.";
}
leaf attributes {
type bits {
bit PARTITIONNED {
description
"If set, the originator supports partition
repair.";
}
bit ATTACHED-ERROR {
description
"If set, the originator is attached to
another area using the referred metric.";
}
Litkowski, et al. Expires April 27, 2015 [Page 37]
Internet-Draft isis-cfg October 2014
bit ATTACHED-EXPENSE {
description
"If set, the originator is attached to
another area using the referred metric.";
}
bit ATTACHED-DELAY {
description
"If set, the originator is attached to
another area using the referred metric.";
}
bit ATTACHED-DEFAULT {
description
"If set, the originator is attached to
another area using the referred metric.";
}
bit OVERLOAD {
description
"If set, the originator is overloaded,
and must be avoided in path calculation.";
}
}
description
"This leaf describes attributes of the LSP.";
}
container is-neighbor {
list neighbor {
key "neighbor-id";
uses neighbor;
description
"List of neighbors.";
}
description
"This leaf describes list of ISIS neighbors.
ISIS reference is TLV 2.";
}
container authentication {
leaf authentication-type {
type authentication-type;
description
"This leaf describes the authentication type
to be used.";
}
leaf authentication-key {
type string;
description
"This leaf describes the authentication key
Litkowski, et al. Expires April 27, 2015 [Page 38]
Internet-Draft isis-cfg October 2014
to be used. For security reason, the
authentication key MUST NOT be presented
in plaintext format. Authors recommends
to use MD5 hash to present the authentication-key.";
}
description "This container describes authentication
information of the node. ISIS reference is TLV 10.";
}
container extended-is-neighbor {
list neighbor {
key "neighbor-id";
uses neighbor-extended;
description
"List of neighbors.";
}
description
"This container describes list of ISIS extended
neighbors.
ISIS reference is TLV 22.";
}
container ipv4-internal-reachability {
list prefixes {
key "ip-prefix";
uses prefix-ipv4-std;
description
"List of prefixes.";
}
description
"This container describes list of IPv4 internal
reachability information.
ISIS reference is TLV 128.";
}
leaf-list protocol-supported {
type uint8;
description
"This leaf describes the list of
supported protocols.
ISIS reference is TLV 129.";
}
container ipv4-external-reachability {
list prefixes {
key "ip-prefix";
uses prefix-ipv4-std;
description
Litkowski, et al. Expires April 27, 2015 [Page 39]
Internet-Draft isis-cfg October 2014
"List of prefixes.";
}
description
"This container describes list of IPv4 external
reachability information.
ISIS reference is TLV 130.";
}
leaf-list ipv4-addresses {
type inet:ipv4-address;
description
"This leaf describes the IPv4 addresses of the node.
ISIS reference is TLV 132.";
}
leaf ipv4-te-routerid {
type inet:ipv4-address;
description
"This leaf describes the IPv4 Traffic Engineering
router ID of the node.
ISIS reference is TLV 134.";
}
container extended-ipv4-reachability {
list prefixes {
key "ip-prefix";
uses prefix-ipv4-extended;
description
"List of prefixes.";
}
description
"This container describes list of IPv4 extended
reachability information.
ISIS reference is TLV 135.";
}
leaf dynamic-hostname {
type string;
description
"This leaf describes the name of the node.
ISIS reference is TLV 137.";
}
leaf ipv6-te-routerid {
type inet:ipv6-address;
Litkowski, et al. Expires April 27, 2015 [Page 40]
Internet-Draft isis-cfg October 2014
description
"This leaf describes the IPv6 Traffic Engineering
router ID of the node.
ISIS reference is TLV 140.";
}
container mt-is-neighbor {
list neighbor {
key "neighbor-id";
leaf MT-ID {
type uint16 {
range "0 .. 4095";
}
description
"This leaf defines the identifier
of a topology.";
}
uses neighbor-extended;
description
"List of neighbors.";
}
description
"This container describes list of ISIS multi-topology
neighbors.
ISIS reference is TLV 223.";
}
container mt-entries {
list topology {
key "MT-ID";
leaf MT-ID {
type uint16 {
range "0 .. 4095";
}
description
"This leaf defines the identifier
of a topology.";
}
leaf attributes {
type bits {
bit OVERLOAD {
description
"If set, the originator is overloaded,
and must be avoided in path
calculation.";
Litkowski, et al. Expires April 27, 2015 [Page 41]
Internet-Draft isis-cfg October 2014
}
bit ATTACHED {
description
"If set, the originator is attached to
another area using the referred metric.";
}
}
description
"This leaf describes attributes of the LSP
for the associated topology.";
}
description
"List of topologies supported.";
}
description
"This container describes the topology supported.
ISIS reference is TLV 229.";
}
leaf-list ipv6-addresses {
type inet:ipv6-address;
description
"This leaf describes the IPv6 interface
addresses of the node.
ISIS reference is TLV 232.";
}
container mt-extended-ipv4-reachability {
list prefixes {
key "ip-prefix";
leaf MT-ID {
type uint16 {
range "0 .. 4095";
}
description
"This leaf defines the identifier
of a topology.";
}
uses prefix-ipv4-extended;
description
"List of prefixes.";
}
description
"This container describes list of IPv4
bearer) allowing communication with the terminals. These communicate
using a set of return channels.
Forward broadcast
MPEG-2 TS \
----------------X /-----\
/ / \
| Receiver|
/----------+ A |
/ \ /
/-----\ / \-----/
/ \ /
| Hub |/
| +\ /-----\
\ / \ / \
\-----/ \ | Receiver|
\-----------+ B |
\ /
\-----/
Figure 6: MPEG-2 Transmission Network with 2 Receivers
There are three possibilities for unicast AR:
(1) A system at a Receiver, A, needs to resolve an address of a
system that is at the Hub;
(2) A system at a Receiver, A, needs to resolve an address that is at
another Receiver, B;
(3) A host at the Hub needs to resolve an address that is at a
Receiver. The sender (encapsulation gateway), uses AR to provide
the MPEG TS Multiplex, PID, MAC/NPA address for sending unicast,
IPv4 subnet broadcast and multicast packets.
If the Hub is an IP router, then case (1) and (2) are the same: The
host at the Receiver does not know the difference. In these cases,
the address to be determined is the L2 address of the device at the
Hub to which the IP packet should be forwarded, which then relays the
IP packet back to the forward (broadcast) MPEG-2 channel after AR
(case 3).
If the Hub is an L2 bridge, then case 2 still has to relay the IP
packet back to the outbound MPEG-2 channel. The AR protocol needs to
resolve the specific Receiver L2 MAC address of B, but needs to send
this on an L2 channel to the Hub. This requires Receivers to be
informed of the L2 address of other Receivers.
Montpetit, et al. Informational [Page 24]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
An end host connected to the Hub needs to use the AR protocol to
resolve the Receiver terminal MAC/NPA address. This requires the AR
server at the Hub to be informed of the L2 addresses of other
Receivers.
5.2. Scenarios for MPEG AR
An AR protocol may transmit AR information in three distinct ways:
(i) An MPEG-2 signalling table transmitted at the MPEG-2 level
(e.g., within the control plane using a Table);
(ii) An MPEG-2 signalling table transmitted at the IP level (no
implementations of this are known);
(iii) An address resolution protocol transported over IP (as in ND
for IPv6)
There are three distinct cases in which AR may be used:
(i) Multiple TS-Muxes and the use of re-multiplexors, e.g., Digital
Terrestrial, Satellite TV broadcast multiplexes. Many such
systems employ remultiplexors that modify the PID values
associated with TS Logical Channels as they pass through the
MPEG-2 transmission network (as in Scenario A of Section 3.1).
(ii) Tuner configuration(s) that are fixed or controlled by some
other process. In these systems, the PID value associated with
a TS Logical Channel may be known by the Sender.
(iii) A service run over one TS Mux (i.e., uses only one PID, for
example DOCSIS and some current DVB-RCS multicast systems). In
these systems, the PID value of a TS Logical Channel may be
known by the Sender.
5.2.1. Table-Based AR over MPEG-2
In current deployments of MPEG-2 networks, information about the set
of MPEG-2 TS Logical Channels carried over a TS Multiplex is usually
distributed via tables (service information, SI) sent using channels
assigned a specific (well-known) set of PIDs. This was originally
designed for audio/video distribution to STBs. This design requires
access to the control plane by processing the SI table information
(carried in MPEG-2 section format [ISO-DSMCC]). The scheme reflects
the complexity of delivering and coordinating the various TS Logical
Channels associated with a multimedia TV program.
Montpetit, et al. Informational [Page 25]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
One possible requirement to provide TS multiplex and PID information
for IP services is to integrate additional information into the
existing MPEG-2 tables, or to define additional tables specific to
the IP service. The DVB INT and the A/92 Specification from ATSC
[ATSC-A92] are examples of the realization of such a solution.
5.2.2. Table-Based AR over IP
AR information could be carried over a TS data channel (e.g., using
an IP protocol similar to the Service Announcement Protocol, SAP).
Implementing this independently of the SI tables would ease
implementation, by allowing it to operate on systems where IP
processing is performed in a software driver. It may also allow the
technique to be more easily adapted to other similar delivery
networks. It also is advantageous for networks that use the MPEG-2
TS, but do not necessarily support audio/video services and therefore
do not need to provide interoperability with TV equipment (e.g.,
links used solely for connecting IP (sub)networks).
5.2.3. Query/Response AR over IP
A query/response protocol may be used at the IP level (similar to, or
based on IPv6 Neighbor Advertisements of the ND protocol). The AR
protocol may operate over an MPEG-2 TS Logical Channel using a
previously agreed PID (e.g., configured, or communicated using a SI
table). In this case, the AR could be performed by the target system
itself (as in ARP and ND). This has good soft-state properties, and
is very tolerant to failures. To find an address, a system sends a
"query" to the network, and the "target" (or its proxy) replies.
5.3. Unicast Address Scoping
In some cases, an MPEG-2 Transmission Network may support multiple IP
networks. When this is the case, it is important to recognize the
context (scope) within which an address is resolved, to prevent
packets from one addressed scope from leaking into other scopes.
An example of overlapping IP address assignments is the use of
private unicast addresses (e.g., in IPv4, 10/8 prefix; 172.16/12
prefix; 192.168/16 prefix). These should be confined to the area to
which they are addressed.
There is also a requirement for multicast address scoping (Section
6.2).
Montpetit, et al. Informational [Page 26]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
IP packets with these addresses must not be allowed to travel outside
their intended scope, and may cause unexpected behaviour if allowed
to do so. In addition, overlapping address assignments can arise
when using level 2 NPA addresses:
(i) The NPA address must be unique within the TS Logical Channel.
Universal IEEE MAC addresses used in Ethernet LANs are
globally unique. If the NPA addresses are not globally
unique, the same NPA address may be re-used by Receivers in
different addressed areas.
(ii) The NPA broadcast address (all 1s MAC address). Traffic with
this address should be confined to one addressed area.
Reception of unicast packets destined for another addressed area may
lead to an increase in the rate of received packets by systems
connected via the network. IP end hosts normally filter received
unicast IP packets based on their assigned IP address. Reception of
the additional network traffic may contribute to processing load but
should not lead to unexpected protocol behaviour. However, it does
introduce a potential Denial of Service (DoS) opportunity.
When the Receiver acts as an IP router, the receipt of such an IP
packet may lead to unexpected protocol behaviour. This also provides
a security vulnerability since arbitrary packets may be passed to the
IP layer.
5.4. AR Authentication
In many AR designs, authentication has been overlooked because of the
wired nature of most existing IP networks, which makes it easy to
control hosts that are physically connected [RFC3819]. With wireless
connections, this is changing: unauthorized hosts actually can claim
L2 resources. The address resolution client (i.e., Receiver) may
also need to verify the integrity and authenticity of the AR
information that it receives. There are trust relationships both
ways: clients need to know they have a valid server and that the
resolution is valid. Servers should perform authorisation before
they allow an L2 address to be used.
The MPEG-2 Transmission Network may also require access control to
prevent unauthorized use of the TS Multiplex; however, this is an
orthogonal issue to address resolution.
Montpetit, et al. Informational [Page 27]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
5.5. Requirements for Unicast AR over MPEG-2
The requirement for AR over MPEG-2 networks include:
(i) Use of a table-based approach to promote AR scaling. This
requires definition of the frequency of update and volume of
AR traffic generated.
(ii) Mechanisms to install AR information at the server
(unsolicited registration).
(iii) Mechanisms to verify AR information held at the server
(solicited responses). Appropriate timer values need to be
defined.
(iv) An ability to purge client AR information (after IP network
renumbering, etc.).
(v) Support of IP subnetwork scoping.
(vi) Appropriate security associations to authenticate the sender.
6. Multicast Support
This section addresses specific issues concerning IPv4 and IPv6
multicast [RFC1112] over MPEG-2 Transmission Networks. The primary
goal of multicast support will be efficient filtering of IP multicast
packets by the Receiver, and the mapping of IPv4 and IPv6 multicast
addresses [RFC3171] to the associated PID value and TS Multiplex.
The design should permit a large number of active multicast groups,
and should minimize the processing load at the Receiver when
filtering and forwarding IP multicast packets. For example, schemes
that may be easily implemented in hardware would be beneficial, since
these may relieve drivers and operating systems from discarding
unwanted multicast traffic [RFC3819].
Multicast mechanisms are used at more than one protocol level. The
upstream router feeding the MPEG-2 Encapsulator may forward multicast
traffic on the MPEG-2 TS Multiplex using a static or dynamic set of
groups. When static forwarding is used, the set of IP multicast
groups may also be configured or set using SNMP, Telnet, etc. A
Receiver normally uses either an IP group management protocol (IGMP
[RFC3376] for IPv4 or MLD [RFC2710][RFC3810] for IPv6) or a multicast
routing protocol to establish tables that it uses to dynamically
enable local forwarding of received groups. In a dynamic case, this
Montpetit, et al. Informational [Page 28]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
group membership information is fed back to the sender to enable it
to start sending new groups and (if required) to update the tables
that it produces for multicast AR.
Appropriate procedures need to identify the correct action when the
same multicast group is available on more than one TS Logical
Channel. This could arise when different end hosts act as senders to
contribute IP packets with the same IP group destination address.
The correct behaviour for SSM [RFC3569] addresses must also be
considered. It may also arise when a sender duplicates the same IP
group over several TS Logical Channels (or even different TS
Multiplexes), and in this case a Receiver may potentially receive
more than one copy of the same packet. At the IP level, the
host/router may be unaware of this duplication.
6.1. Multicast AR Functions
The functions required for multicast AR may be summarized as:
(i) The Sender needs to know the L2 mapping of a multicast group.
(ii) The Receiver needs to know the L2 mapping of a multicast group.
In the Internet, multicast AR is normally a mapping function rather
than a one-to-one association using a protocol. In Ethernet, the
sender maps an IP address to an L2 MAC address, and the Receiver uses
the same mapping to determine the L2 address to set an L2
hardware/software filter entry.
A typical sequence of actions for the dynamic case is:
L3) Populate the IP L3 membership tables at the Receiver.
L3) Receivers send/forward IP L3 membership tables to the Hub
L3) Dynamic/static forwarding at hub/upstream router of IP L3
groups
L2) Populate the IP AR tables at the encapsulator gateway
(i.e., Map IP L3 mcast groups to L2 PIDs)
L2) Distribute the AR information to Receivers
L2) Set Receiver L2 multicast filters for IP groups in the
membership table.
Montpetit, et al. Informational [Page 29]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
To be flexible, AR must associate a TS Logical Channel (PID) not only
with a group address, but possibly also a QoS class and other
appropriate MPEG-2 TS attributes. Explicit per group AR to
individual L2 addresses is to be avoided.
\
|
+---+----+ +---------+
| Tuner |---+TS Table | . . . .
+---+----+ +---------+ .
| - .
+--------+ +---------+ .
| deMux |---+PID Table|........
+---+----+ +---------+ :
| - :
+--------+ +---------+ +------------+
|MPE/ULE |---+AR Cache-|---+ L2 Table |
+---+----+ +---------+ +------------+
| | |
+---+----+ +---+-----+ +---+----+
| IP | | AR | |IGMP/MLD|
+---+----+ +---+-----+ +---+----+
| | |
*------------+------------+
Figure 7: Receiver Processing Architecture
6.2. Multicast Address Scoping
As in unicast, it is important to recognize the context (scope)
within which a multicast IP address is resolved, to prevent packets
from one addressed scope leaking into other scopes.
Examples of overlapping IP multicast address assignments include:
(i) Local scope multicast addresses. These are
only valid within the local area (examples for IPv4
include: 224.0.0/24; 224.0.1/24). Similar cases
exist for some IPv6 multicast addresses [RFC2375].
(ii) Scoped multicast addresses [RFC2365] [RFC 2375]. Forwarding
of these addresses is controlled by the scope associated
with the address. The addresses are only valid with an
addressed area (e.g. the 239/8 [RFC2365]).
(iii) Other non-IP protocols may also view sets of MAC multicast
addresses as link-local, and may produce unexpected results
if distributed across several private networks.
Montpetit, et al. Informational [Page 30]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
IP packets with these addresses must not be allowed to travel outside
their intended scope (see Section 5.3). Performing multicast AR at
the IP level can enable providers to offer independently scoped
addresses and would need to use multiple Multicast AR servers, one
per multicast domain.
6.3. Requirements for Multicast over MPEG-2
The requirements for supporting multicast include, but are not
restricted to:
(i) Encapsulating multicast packets for transmission using an
MPEG-2 TS.
(ii) Mapping IP multicast groups to the underlying MPEG-2 TS
Logical Channel (PID) and the MPEG-2 TS Multiplex.
(iii) Providing AR information to allow a Receiver to locate an
IP multicast flow within an MPEG-2 TS Multiplex.
(iv) Error Reporting.
7. Summary
This document describes the architecture for a set of protocols to
perform efficient and flexible support for IP network services over
networks built upon the MPEG-2 Transport Stream (TS). It also
describes existing approaches. The focus is on IP networking, the
mechanisms that are used, and their applicability to supporting IP
unicast and multicast services.
The requirements for a new encapsulation of IPv4 and IPv6 packets is
described, outlining the limitations of current methods and the need
for a streamlined IP-centric approach.
The architecture also describes MPEG-2 Address Resolution (AR)
procedures to allow dynamic configuration of the sender and Receiver
using an MPEG-2 transmission link/network. These support IPv4 and
IPv6 services in both the unicast and multicast modes. Resolution
protocols will support IP packet transmission using both the
Multiprotocol Encapsulation (MPE), which is currently widely
deployed, and also any IETF-defined encapsulation (e.g., ULE
[IPDVB-ULE]).
Montpetit, et al. Informational [Page 31]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
8. Security Considerations
When the MPEG-2 transmission network is not using a wireline network,
the normal security issues relating to the use of wireless links for
transport of Internet traffic should be considered [RFC3819].
End-to-end security (including confidentiality, authentication,
integrity and access control) is closely associated with the end user
assets that are protected. This close association cannot be ensured
when providing security mechanisms only within a subnetwork (e.g., an
MPEG-2 Transmission Network). Several security mechanisms that can
be used end-to-end have already been deployed in the general Internet
and are enjoying increasing use. Important examples include:
- Transport Layer Security (TLS), which is primarily used to
protect web commerce;
- Pretty Good Privacy (PGP) and S/MIME, primarily used to protect
and authenticate email and software distributions;
- Secure Shell (SSH), used to secure remote access and file
transfer;
- IPsec, a general purpose encryption and authentication mechanism
above IP that can be used by any IP application.
However, subnetwork security is also important [RFC3819] and should
be encouraged, on the principle that it is better than the default
situation, which all too often is no security at all. Users of
especially vulnerable subnets (such as radio/broadcast networks
and/or shared media Internet access) often have control over, at
most, one endpoint - usually a client - and therefore cannot enforce
the use of end-to-end mechanisms.
A related role for subnetwork security is to protect users against
traffic analysis, i.e., identifying the communicating parties (by IP
or MAC address) and determining their communication patterns, even
when their actual contents are protected by strong end-to-end
security mechanisms. (This is important for networks such as
broadcast/radio, where eavesdropping is easy.)
Encryption performed at the Transport Stream (encrypting the payload
of all TS-Packets with the same PID) encrypts/scrambles all parts of
the SNDU, including the layer 2 MAC/NPA address. Encryption at the
section level in MPE may also optionally encrypt the layer 2 MAC/NPA
address in addition to the PDU data [ETSI-DAT]. In both cases,
encryption of the MAC/NPA address requires a Receiver to decrypt all
encrypted data, before it can then filter the PDUs with the set of
Montpetit, et al. Informational [Page 32]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
MAC/NPA addresses that it wishes to receive. This method also has
the drawback that all Receivers must share a common encryption key.
Encryption of the MPE MAC address is therefore not permitted in some
systems (e.g., [ETSI-DVBRCS]).
Where it is possible for an attacker to inject traffic into the
subnetwork control plane, subnetwork security can additionally
protect the subnetwork assets. This threat must specifically be
considered for the protocols used for subnetwork control functions
(e.g., address resolution, management, configuration). Possible
threats include theft of service and denial of service; shared media
subnets tend to be especially vulnerable to such attacks [RFC3819].
Appropriate security functions must therefore be provided for IPDVB
control protocols [RFC3819], particularly when the control functions
are provided above the IP-layer using IP-based protocols. Internet
level security mechanisms (e.g., IPsec) can mitigate such threats.
In general, End-to-End security is recommended for users of any
communication path, especially when it includes a wireless/radio or
broadcast link, where a range of security techniques already exist.
Specification of security mechanisms at the application layer, or
within the MPEG-2 transmission network, are the concerns of
organisations beyond the IETF. The complexity of any such security
mechanisms should be considered carefully so that it will not unduly
impact IP operations.
8.1. Link Encryption
Link level encryption of IP traffic is commonly used in
broadcast/radio links to supplement End-to-End security (e.g.,
provided by TLS, SSH, Open PGP, S/MIME, IPsec). The encryption and
key exchange methods vary significantly, depending on the intended
application. For example, DVB-S/DVB-RCS operated by Access Network
Operators may wish to provide their customers (Internet Service
Providers, ISP) with security services. Common security services
are: terminal authentication and data confidentiality (for unicast
and multicast) between an encapsulation gateway and Receivers. A
common objective is to provide the same level of privacy as
terrestrial links. An ISP may also wish to provide end-to-end
security services to the end-users (based on well-known mechanisms
such as IPsec).
Therefore, it is important to understand that both security solutions
(Access Network Operators to ISP and ISP to end-users) may coexist.
Montpetit, et al. Informational [Page 33]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
MPE supports optional link encryption [ETSI-DAT]. A pair of bits
within the MPE protocol header indicate whether encryption
(scrambling) is used. For encrypted PDUs, the header bits indicate
which of a pair of previously selected encryption keys is to be used.
It is recommended that any new encapsulation defined by the IETF
allows Transport Stream encryption and also supports optional link
level encryption/authentication of the SNDU payload. In ULE
[IPDVB-ULE], this may be provided in a flexible way using Extension
Headers. This requires definition of a mandatory header extension,
but has the advantage that it decouples specification of the security
functions from the encapsulation functions. This method also
supports encryption of the NPA/MAC addresses.
9. IANA Considerations
A set of protocols that meet these requirements will require the IANA
to make assignments. This document in itself, however, does not
require any IANA involvement.
10. Acknowledgements
The authors wish to thank Isabel Amonou, Torsten Jaekel, Pierre
Loyer, Luoma Juha-Pekka, and Rod Walsh for their detailed inputs. We
also wish to acknowledge the input provided by the members of the
IETF ipdvb WG.
11. References
11.1. Normative References
[ISO-MPEG] ISO/IEC DIS 13818-1:2000, "Information Technology;
Generic Coding of Moving Pictures and Associated Audio
Information Systems", International Standards
Organisation (ISO).
[ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB
Specifications for Data Broadcasting", European
Telecommunications Standards Institute (ETSI).
11.2. Informative References
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced
Television Systems Committee (ATSC), Doc. A/53C, 2004.
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced
Television Systems Committee (ATSC), Doc. A/090, 2000.
Montpetit, et al. Informational [Page 34]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines
for the ATSC Data Broadcast Standard", Advanced
Television Systems Committee (ATSC), Doc. A/91, 2001.
[ATSC-A92] A/92, "Delivery of IP Multicast Sessions over ATSC
Data Broadcast", Advanced Television Systems Committee
(ATSC), Doc. A/92, 2002.
[ATSC-G] A/54A, "Guide to the use of the ATSC Digital
Television Standard", Advanced Television Systems
Committee (ATSC), Doc. A/54A, 2003.
[ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for
Terrestrial Broadcast and Cable", Advanced Television
Systems Committee (ATSC), Doc. A/65B, 2003.
[ATSC-S] A/80, "Modulation and Coding Requirements for Digital
TV (DTV) Applications over Satellite", Advanced
Television Systems Committee (ATSC), Doc. A/80, 1999.
[CLC99] Clausen, H., Linder, H., and Collini-Nocker, B.,
"Internet over Broadcast Satellites", IEEE Commun.
Mag. 1999, pp.146-151.
[ETSI-BSM] TS 102 292, "Satellite Earth Stations and Systems
(SES); Broadband Satellite Multimedia Services and
Architectures; Functional Architecture for IP
Interworking with BSM networks", European
Telecommunications Standards Institute (ETSI).
[ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB
interaction channel for Cable TV distribution systems
(CATV)", European Telecommunications Standards
Institute (ETSI).
[ETSI-DVBRCS] EN 301 790, "Digital Video Broadcasting (DVB);
Interaction channel for satellite distribution
systems", European Telecommunications Standards
Institute (ETSI).
[ETSI-DVBS] EN 301 421,"Digital Video Broadcasting (DVB);
Modulation and Coding for DBS satellite systems at
11/12 GHz", European Telecommunications Standards
Institute (ETSI).
Montpetit, et al. Informational [Page 35]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
[ETSI-DVBS2] EN 302 207, "Second generation framing structure,
channel coding and modulation systems for
Broadcasting, Interactive Services,News Gathering and
Other Broadband Satellite Applications", European
Telecommunications Standards Institute (ETSI).
[ETSI-DVBT] EN 300 744, "Digital Video Broadcasting (DVB); Framing
structure, channel coding and modulation for digital
terrestrial television (DVB-T)", European
Telecommunications Standards Institute (ETSI).
[ETSI-IPDC] "IP Datacast Specification", DVB Interim Specification
CNMS 1026 v1.0.0,(Work in Progress), April 2004.
[ETSI-MHP] TS 101 812, "Digital Video Broadcasting (DVB);
Multimedia Home Platform (MHP) Specification", v1.2.1,
European Telecommunications Standards Institute
(ETSI), June 2002.
[ETSI-RC] ETS 300 802, "Digital Video Broadcasting (DVB);
Network-independent protocols for DVB interactive
services", European Telecommunications Standards
Institute (ETSI).
[ETSI-SI] EN 300 468, "Digital Video Broadcasting (DVB);
Specification for Service Information (SI) in DVB
systems", European Telecommunications Standards
Institute (ETSI).
[IPDVB-ULE] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for transmission of IP
datagrams over an MPEG-2 Transport Stream", Work in
Progress, June 2005.
[IPDVB-AR] Fairhurst, G. and M-J. Montpetit, "Address Resolution
for IP datagrams over MPEG-2 networks", Work in
Progress, 2005.
[ISO-AUD] ISO/IEC 13818-3:1995, "Information technology; Generic
coding of moving pictures and associated audio
information; Part 3: Audio", International Standards
Organisation (ISO).
[ISO-DSMCC] ISO/IEC IS 13818-6, "Information technology; Generic
coding of moving pictures and associated audio
information; Part 6: Extensions for DSM-CC",
International Standards Organisation (ISO).
Montpetit, et al. Informational [Page 36]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
[ISO-VID] ISO/IEC DIS 13818-2:1998, "Information technology;
Generic coding of moving pictures and associated audio
information; Video&Litkowski, et al. Expires April 27, 2015 [Page 42]
Internet-Draft isis-cfg October 2014
reachability information in multi-topology
environment.
ISIS reference is TLV 235.";
}
container mt-ipv6-reachability {
list prefixes {
key "ip-prefix";
leaf MT-ID {
type uint16 {
range "0 .. 4095";
}
description
"This leaf defines the identifier
of a topology.";
}
uses prefix-ipv6-extended;
description
"List of prefixes.";
}
description
"This container describes list of IPv6
reachability information in multi-topology
environment.
ISIS reference is TLV 237.";
}
container ipv6-reachability {
list prefixes {
key "ip-prefix";
uses prefix-ipv6-extended;
description
"List of prefixes.";
}
description
"This container describes list of IPv6
reachability information.
ISIS reference is TLV 236.";
}
container router-capabilities {
leaf binary {
type binary;
description
"This leaf describes the capability of the node.
Format is binary according to the protocol encoding.";
}
description
Litkowski, et al. Expires April 27, 2015 [Page 43]
Internet-Draft isis-cfg October 2014
"This container describes the capabilities of the node.
This container may be extended with detailed
information.
ISIS reference is TLV 242.";
}
}
augment "/rt:routing/rt:routing-instance/rt:routing-protocols/"
+"rt:routing-protocol" {
when "rt:type = 'isis:isis'" {
description
"This augment is only valid when routing protocol
instance type is isis.";
}
description
"This augments a routing protocol instance with ISIS
specific parameters.";
container isis {
list instance {
must "count(area-address) > 0" {
error-message "At least one area-address
must be configured.";
description
"Enforce configuration of at least one area.";
}
key routing-instance;
leaf routing-instance {
type rt:routing-instance-ref;
description
"Reference routing instance.
For protocol centric model, which is
supported in
default-instance only, this could reference
any VRF routing-instance.
For VRF centric model, must reference the
enclosing routing-instance.";
}
leaf level-type {
type level;
default "level-all";
Litkowski, et al. Expires April 27, 2015 [Page 44]
Internet-Draft isis-cfg October 2014
description
"This leaf describes the type of ISIS node.
A node can be level-1-only, level-2-only
or level-1-2.
";
}
leaf system-id {
type system-id;
description
"This leaf defines the system-id of the node.";
}
leaf maximum-area-addresses {
if-feature maximum-area-addresses;
type uint8;
default 3;
description
"Defines the maximum areas supported.";
}
leaf-list area-address {
type area-address;
description
"List of areas supported by the
protocol instance.";
}
container mpls-te {
leaf ipv4-router-id {
if-feature ipv4-router-id;
type inet:ipv4-address;
description
"Router ID value that would be used in
TLV 134.";
}
leaf ipv6-router-id {
if-feature ipv6-router-id;
type inet:ipv6-address;
description
"Router ID value that would be used in
TLV 140.";
}
description
"This container handles mpls te config.";
}
leaf reference-bandwidth {
Litkowski, et al. Expires April 27, 2015 [Page 45]
Internet-Draft isis-cfg October 2014
if-feature reference-bandwidth;
type uint32;
units "bps";
description
"This leaf defines the bandwidth for calculating
metric.";
}
leaf lsp-mtu {
type uint16;
units "bytes";
default 1492;
description
"This leaf describes the maximum size of a
LSP PDU in bytes.";
}
leaf lsp-lifetime {
type uint16;
units "seconds";
description
"This leaf describes the lifetime of the router
LSP in seconds.";
}
leaf lsp-refresh {
if-feature lsp-refresh;
type uint16;
units "seconds";
description
"This leaf describes the refresh interval of the
router LSP in seconds.";
}
container graceful-restart {
if-feature graceful-restart;
leaf enabled {
type boolean;
description
"Control enabling the feature.";
}
description
"This container activates graceful restart.";
}
list authentication {
key level;
leaf key {
type string;
Litkowski, et al. Expires April 27, 2015 [Page 46]
quot;, International Standards
Organisation (ISO).
[ITU-AAL5] ITU-T I.363.5, "B-ISDN ATM Adaptation Layer
Specification Type AAL5", International Standards
Organisation (ISO), 1996.
[LLC] ISO/IEC 8802.2, "Information technology;
Telecommunications and information exchange between
systems; Local and metropolitan area networks;
Specific requirements; Part 2: Logical Link Control",
International Standards Organisation (ISO), 1998.
[MMUSIC-IMG] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H.
Schulzrinne, "Requirements for Internet Media Guides",
Work in Progress, June 2004.
[OPEN-CABLE] "Open Cable Application Platform Specification; OCAP
2.0 Profile", OC-SP-OCAP2.0-I01-020419, Cable Labs,
April 2002.
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
23, RFC 2365, July 1998.
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, July 1998.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October
1999.
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999.
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and
Y. Zhang, "A Link-Layer Tunneling Mechanism for
Unidirectional Links", RFC 3077, March 2001.
Montpetit, et al. Informational [Page 37]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima,
H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren,
T., Le, K., Liu, Z., Martensson, A., Miyazaki, A.,
Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng,
"RObust Header Compression (ROHC): Framework and four
profiles: RTP, UDP, ESP, and uncompressed", RFC 3095,
July 2001.
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address
Assignments", BCP 51, RFC 3171, August 2001.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
A. Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J.,
and L. Wood, "Advice for Internet Subnetwork
Designers", BCP 89, RFC 3819, July 2004 .
Montpetit, et al. Informational [Page 38]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
Appendix A: MPEG-2 Encapsulation Mechanisms
Transmitting packet data over an MPEG-2 transmission network requires
that individual PDUs (e.g., IPv4, IPv6 packets, or bridged Ethernet
Frames) are encapsulated using a convergence protocol. The following
encapsulations are currently standardized for MPEG-2 transmission
networks:
(i) Multi-Protocol Encapsulation (MPE).
The MPE specification of DVB [ETSI-DAT] uses private
Sections for the transport of IP packets and uses
encapsulation that is similar to the IEEE LAN/MAN standards
[LLC]. Data packets are encapsulated in datagram sections
that are compliant with the DSMCC section format for private
data. Some Receivers may exploit section processing
hardware to perform a first-level filtering of the packets
that arrive at the Receiver.
This encapsulation makes use of a MAC-level Network Point of
Attachment address. The address format conforms to the
ISO/IEEE standards for LAN/MAN [LLC]. The 48-bit MAC
address field contains the MAC address of the destination;
it is distributed over six 8-bit fields, labelled
MAC_address_1 to MAC_address_6. The MAC_address_1 field
contains the most significant byte of the MAC address, while
MAC_address_6 contains the least significant byte. How many
of these bytes are significant is optional and defined by
the value of the broadcast descriptor table [ETSI-DAT] sent
separately over another MPEG-2 TS within the TS multiplex.
MPE is currently a widely deployed scheme. Due to
Investments in existing systems, usage is likely to continue
in current and future MPEG-2 Transmission Networks. ATSC
provides a scheme similar to MPE [ATSC-DAT] with some small
differences.
(ii) Data Piping.
The Data Piping profile [ETSI-DAT] is a minimum overhead,
simple and flexible profile that makes no assumptions
concerning the format of the data being sent. In this
profile, the Receiver is intended to provide PID filtering,
packet reassembly according to [ETSI-SI], error detection,
and optional Conditional Access (link encryption).
Montpetit, et al. Informational [Page 39]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
The specification allows the user data stream to be
unstructured or organized into packets. The specific
structure is transparent to the Receiver. It may conform to
any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES,
etc.
(iii) Data Streaming.
The data broadcast specification profile [ETSI-DAT] for PES
tunnels (Data Streaming) supports unicast and multicast data
services that require a stream-oriented delivery of data
packets. This encapsulation maps an IP packet into a single
PES Packet payload.
Two different types of PES headers can be selected via the
stream_id values [ISO-MPEG]. The private_stream_2 value
permits the use of the short PES header with limited
overhead, while the private_stream_1 value makes available
the scrambling control and the timing and clock reference
features of the PES layer.
Montpetit, et al. Informational [Page 40]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
Authors' Addresses
Marie J. Montpetit
Motorola Connected Home Solutions
45 Hayden Avenue 4th Floor
Lexington MA 02130
USA
EMail: mmontpetit@motorola.com
Godred Fairhurst
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
UK
EMail: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry
Horst D. Clausen
TIC Systems
Lawrence, Kansas
EMail: h.d.clausen@ieee.org
Bernhard Collini-Nocker
Department of Scientific Computing
University of Salzburg
Jakob Haringer Str. 2
5020 Salzburg
Austria
EMail: bnocker@cosy.sbg.ac.at
Web: http://www.network-research.org
Hilmar Linder
Department of Scientific Computing
University of Salzburg
Jakob Haringer Str. 2
5020 Salzburg
Austria
EMail: hlinder@cosy.sbg.ac.at
Web: http://www.network-research.org
Montpetit, et al. Informational [Page 41]
RFC 4259 IP Transport over MPEG-2 Networks November 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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
http://www.ietf.org/ipr.
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 ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Montpetit, et al. Informational [Page 42]