public class Notification extends PCEPObject
Represents a PCEP NOTIFICATION Object, as defined in RFC 5440.
From RFC 5440 Section 7.14. NOTIFICATION Object
The NOTIFICATION object is exclusively carried within a PCNtf message
and can either be used in a message sent by a PCC to a PCE or by a
PCE to a PCC so as to notify of an event.
NOTIFICATION Object-Class is 12.
NOTIFICATION Object-Type is 1.
The format of the NOTIFICATION body object is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | NT | NV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: NOTIFICATION Body Object Format
Reserved (8 bits): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
Flags (8 bits): No flags are currently defined. Unassigned flags
MUST be set to zero on transmission and MUST be ignored on
receipt.
NT (Notification Type - 8 bits): The Notification-type specifies the
class of notification.
NV (Notification Value - 8 bits): The Notification-value provides
addition information related to the nature of the notification.
Both the Notification-type and Notification-value are managed by
IANA.
The following Notification-type and Notification-value values are
currently defined:
o Notification-type=1: Pending Request cancelled
Notification-value=1: PCC cancels a set of pending requests. A
Notification-type=1, Notification-value=1 indicates that the
PCC wants to inform a PCE of the cancellation of a set of
pending requests. Such an event could be triggered because of
external conditions such as the receipt of a positive reply
from another PCE (should the PCC have sent multiple requests to
a set of PCEs for the same path computation request), a network
event such as a network failure rendering the request obsolete,
or any other events local to the PCC. A NOTIFICATION object
with Notification-type=1, Notification-value=1 is carried
within a PCNtf message sent by the PCC to the PCE. The RP
object corresponding to the cancelled request MUST also be
present in the PCNtf message. Multiple RP objects may be
carried within the PCNtf message; in which case, the
notification applies to all of them. If such a notification is
received by a PCC from a PCE, the PCC MUST silently ignore the
notification and no errors should be generated.
Notification-value=2: PCE cancels a set of pending requests. A
Notification-type=1, Notification-value=2 indicates that the
PCE wants to inform a PCC of the cancellation of a set of
pending requests. A NOTIFICATION object with Notification-
type=1, Notification-value=2 is carried within a PCNtf message
sent by a PCE to a PCC. The RP object corresponding to the
cancelled request MUST also be present in the PCNtf message.
Multiple RP objects may be carried within the PCNtf message; in
which case, the notification applies to all of them. If such
notification is received by a PCE from a PCC, the PCE MUST
silently ignore the notification and no errors should be
generated.
o Notification-type=2: Overloaded PCE
Notification-value=1: A Notification-type=2, Notification-
value=1 indicates to the PCC that the PCE is currently in an
overloaded state. If no RP objects are included in the PCNtf
message, this indicates that no other requests SHOULD be sent
to that PCE until the overloaded state is cleared: the pending
requests are not affected and will be served. If some pending
requests cannot be served due to the overloaded state, the PCE
MUST also include a set of RP objects that identifies the set
of pending requests that are cancelled by the PCE and will not
be honored. In this case, the PCE does not have to send an
additional PCNtf message with Notification-type=1 and
Notification-value=2 since the list of cancelled requests is
specified by including the corresponding set of RP objects. If
such notification is received by a PCE from a PCC, the PCE MUST
silently ignore the notification and no errors should be
generated.
A PCE implementation SHOULD use a dual-threshold mechanism used
to determine whether it is in a congestion state with regards
to specific resource monitoring (e.g. CPU, memory). The use
of such thresholds is to avoid oscillations between overloaded/
non-overloaded state that may result in oscillations of request
targets by the PCCs.
Optionally, a TLV named OVERLOADED-DURATION may be included in
the NOTIFICATION object that specifies the period of time
during which no further request should be sent to the PCE.
Once this period of time has elapsed, the PCE should no longer
be considered in a congested state.
The OVERLOADED-DURATION TLV is compliant with the PCEP TLV
format defined in Section 7.1 and is comprised of 2 bytes for
the type, 2 bytes specifying the TLV length (length of the
value portion in bytes), followed by a fixed-length value field
of a 32-bit flags field.
Type: 2
Length: 4 bytes
Value: 32-bit flags field indicates the estimated PCE
congestion duration in seconds.
Notification-value=2: A Notification-type=2, Notification-
value=2 indicates that the PCE is no longer in an overloaded
state and is available to process new path computation
requests. An implementation SHOULD make sure that a PCE sends
such notification to every PCC to which a Notification message
(with Notification-type=2, Notification-value=1) has been sent
unless an OVERLOADED-DURATION TLV has been included in the
corresponding message and the PCE wishes to wait for the
expiration of that period of time before receiving new
requests. If such notification is received by a PCE from a
PCC, the PCE MUST silently ignore the notification and no
errors should be generated. It is RECOMMENDED to support some
dampening notification procedure on the PCE so as to avoid too
frequent congestion state and congestion state release
notifications. For example, an implementation could make use
of an hysteresis approach using a dual-threshold mechanism that
triggers the sending of congestion state notifications.
Furthermore, in case of high instabilities of the PCE
resources, an additional dampening mechanism SHOULD be used
(linear or exponential) to pace the notification frequency and
avoid oscillation of path computation requests.
When a PCC receives an overload indication from a PCE, it should
consider the impact on the entire network. It must be remembered
that other PCCs may also receive the notification, and so many path
computation requests could be redirected to other PCEs. This may, in
turn, cause further overloading at PCEs in the network. Therefore,
an application at a PCC receiving an overload notification should
consider applying some form of back-off (e.g., exponential) to the
rate at which it generates path computation requests into the
network. This is especially the case as the number of PCEs reporting
overload grows.
Ibit, log, object_bytes, ObjectClass, ObjectLength, OT, Pbit, Res| Constructor and Description |
|---|
Notification() |
Notification(byte[] bytes,
int offset)
Constructs a new NOTIFICATION Object from a sequence of bytes
|
decode, decodeHeader, encode_header, getBytes, getLength, getObject_bytes, getObjectClass, getObjectClass, getObjectLength, getObjectType, getOT, getRes, isIbit, isPbit, setIbit, setObject_bytes, setObjectClass, setObjectLength, setOT, setPbit, setRes, supportedObjectpublic Notification()
public Notification(byte[] bytes,
int offset)
throws MalformedPCEPObjectException
bytes - Sequence of bytes where the object is presentoffset - Position at which the object startsMalformedPCEPObjectException - Thrown if the decoded object is not well formedpublic void encode()
encode in interface PCEPElementencode in class PCEPObjectpublic void decode()
throws MalformedPCEPObjectException
decode in class PCEPObjectMalformedPCEPObjectExceptionpublic int getNotificationType()
public void setNotificationType(int notificationType)
public int getNotificationValue()
public void setNotificationValue(int notificationValue)
public LinkedList<ReachabilityTLV> getReachabilityTLVList()
public void setReachabilityTLVList(LinkedList<ReachabilityTLV> reachabilityTLVList)
public LinkedList<OSPFTE_LSA_TLV> getLSATLVList()
public void setLSATLVList(LinkedList<OSPFTE_LSA_TLV> lSATLVList)
public void addOSPFTE_LSA_TLV(OSPFTE_LSA_TLV ospfte_lsa_tlv)
public void addReachabilityTLV(ReachabilityTLV reachabilityTLV)
public ITAdvertisementTLV getITadvtlv()
public void setITadvtlv(ITAdvertisementTLV ITadvtlv)
public StorageTLV getStoragetlv()
public void setStoragetlv(StorageTLV Storagetlv)
public ServerTLV getServertlv()
public void setServertlv(ServerTLV Servertlv)
public ReservationIDTLV getReservationIDTLV()
public void setReservationIDTLV(ReservationIDTLV reservationIDTLV)
public PathReservationTLV getNotificationTLV()
public void setNotificationTLV(PathReservationTLV notificationTLV)
public ITAdvertisementTLV getITadvTLV()
public void setITadvTLV(ITAdvertisementTLV iTadvTLV)
public StorageTLV getStorageTLV()
public void setStorageTLV(StorageTLV storageTLV)
public ServerTLV getServerTLV()
public void setServerTLV(ServerTLV serverTLV)
public int hashCode()
hashCode in class PCEPObjectpublic boolean equals(Object obj)
equals in class PCEPObjectCopyright © 2016. All rights reserved.