Cisco Systems 78-13983-04 Manual De Usuario

The following features are supported in the network processor:

MAC Classify 

ICMP

FIB (CEF)

Load-balancing 

MAC Rewrite

QoS Matching, including IP Access Lists (Input/Output Security ACLs are not supported), QoS 
Group, IP Precedence, IP DSCP, and Input Interface

QoS Actions, including Set IP Precedence, Set IP DSCP, Set QoS Group, Traffic Shaping, Class 
Based WFQ (CB-WFQ), and Low Latency Queuing (LLQ)

Maintenance of statistics, such as Forwarding, Drop, and Interface

IPv4

MLPPP

MLP, PPP Data Path (MLP LFI is not supported)

PPPmux

cRTP/cUDP

Encapsulated PPP frames contain several bytes of header information, which adds overhead to a network 
that is used to transport PPP frames.

RFC 3153 describes a way to overcome this overhead. On the sending end, a multiplexor concatenates 
multiple PPP frames (subframes) into a single, multiplexed frame (superframe). One header is included 
in the superframe and the individual PPP subframes are separated by delimiters. On the receiving end, 
a demultiplexor uses the delimiters to separate the individual PPP subframes.

The MWR 1900 network processor software conforms to this specification and acts as both a multiplexor 
and a demultiplexor.

RTP is a protocol used for carrying packetized audio and video traffic over an IP network. RTP, 
described in RFC 1889, is not intended for data traffic, which uses TCP or UDP. Instead, RTP provides 
end-to-end network transport functions intended for applications with real-time requirements (such as 
audio, video, or simulation data) over multicast or unicast network services.

In an RTP frame, there is a minimum 12 bytes of the RTP header, combined with 20 bytes of IP header, 
and 8 bytes of UDP header. This creates a 40-byte IP/UDP/RTP header. By comparison, the RTP packet 
has a payload of approximately 20 to 160 bytes for audio applications that use compressed payloads. 
Given this ratio, it is very inefficient to transmit the IP/UDP/RTP header without compressing it.