Added protocol suite highlights

13_wire_protocol.asciidoc

@@ -1,8 +1,6 @@
 [[wire_protocol]]
 == Wire Protocol: Framing & Extensibility
 
-=== Introduction
-
 In this chapter, we'll dive into the wire protocol of the Lightning network,
 and also cover all the various extensibility levers that have been built into
 the protocol. By the end of this chapter, and aspiring reader should be able to
@@ -11,6 +9,14 @@ to being able to write a custom wire protocol parser, a reader of this chapter
 will gain a deep understanding with respect of the various upgrade mechanisms
 that have been built into the protocol.
 
+=== Messaging Layer in the Lightning protocol suite
+
+The messaging layer, which is detailed in this chapter, consists of _Message Framing and Format_, _Type Length Value (TLV)_ encoding, and _Feature Bits_. These components are highlighted by a double outline in the protocol suite, shown in <<LN_protocol_wire_message_highlight>>:
+
+[[LN_protocol_wire_message_highlight]]
+.The Lightning Network Protocol Suite
+image::images/LN_protocol_wire_message_highlight.png["The Lightning Network Protocol Suite"]
+
 === Wire Framing
 
 First, we being by describing the high level structure of the wire _framing_

14_encrypted_transport.asciidoc

@@ -7,6 +7,14 @@ Transport_, also known as the _Brontide Protocol_, which allows peers to
 establish end-to-end encrypted communication, authentication, and integrity
 checking.
 
+=== Encrypted Transport in the Lightning Protocol Suite
+
+The _Encrypted Transport_ component of the Lightning Network and its several components are shown in the left most part of the _Network Connection Layer_ in  <<LN_protocol_encrypted_transport_highlight>>:
+
+[[LN_protocol_encrypted_transport_highlight]]
+.The Lightning Network Protocol Suite
+image::images/LN_protocol_encrypted_transport_highlight.png["The Lightning Network Protocol Suite"]
+
 === Introduction
 
 Unlike the vanilla Bitcoin P2P network, every node in the Lightning Network is
@@ -19,7 +27,7 @@ level. In this chapter, we'll learn about the encryption protocol used by the
 Lightning network in detail. Upon completion of this chapter, the reader will
 be familiar with the state of the art in encrypted messaging protocols, as well
 as the various properties such a protocol provides to the network. It's worth
-mentioning that the core of the encrypted message transport is _agonstic_ to
+mentioning that the core of the encrypted message transport is _agnostic_ to
 its usage within the context of the Lightning Network. As a result, the
 custom encrypted message transport Lightning uses, commonly referred to as
 "Brontide" (more on that later) can be dropped into any context that requires

15_payment_requests.asciidoc

@@ -4,6 +4,14 @@
 
 In this chapter we will look at _Lightning Payment Requests_ or as they are more commonly known _Lightning Invoices_.
 
+=== Invoices in the Lightning Protocol Suite
+
+_Payment Requests_, aka _Invoices_ are part of the Payment Layer and are show in the upper left of <<LN_payment_request_highlight>>:
+
+[[LN_payment_request_highlight]]
+.The Lightning Network Protocol Suite
+image::images/LN_payment_request_highlight.png["The Lightning Network Protocol Suite"]
+
 === Introduction
 
 As we've learned in prior chapters, minimally two pieces of data are required
@@ -214,4 +222,4 @@ underhand that feature in order to complete the payment.
 
 === Conclusion
 
-As we have seen, invoices are a lot more than just a request for an amount. They contain critical information about _how_ to make the payment, such as "routing hints", the destination node's public key, ephemeral keys to increase security and much more. 
+As we have seen, invoices are a lot more than just a request for an amount. They contain critical information about _how_ to make the payment, such as "routing hints", the destination node's public key, ephemeral keys to increase security and much more.